16 июня 2020 ForkLog
Задачи и архитектура
Перед разработкой собственного блокчейна ваша команда должна четко понимать, для чего необходим блокчейн и какой бюджет вы сможете выделить на его содержание.
Проектирование и запуск блокчейна имеют свои нюансы. Их можно легко упустить при планировании, если вы неверно оценили объем и сложность задачи.
Чтобы помочь проектам избежать таких ошибок, руководитель отдела исследований MixBytes Сергей Прилуцкий подготовил пошаговое руководство по запуску блокчейна.
Определение круга технических задач
Задача блокчейна — принимать от пользователей транзакции и точным и неоспоримым способом обрабатывать каждую из них. Результаты работы каждой транзакции записываются в общедоступную базу данных (state database) на каждой машине блокчейн-сети. Любой участник может воспроизвести и перепроверить эту базу данных, если у него есть данные о ее первоначальном состоянии и журнал всех транзакций или блоков.
Чтобы правильно выбрать блокчейн, техническим специалистам прежде всего нужно определить типы транзакций и как будет работать каждая из них. Для классификации удобно использовать традиционные серверные ресурсы: процессор, оперативная память, сетевой трафик, хранилище (cpu, mem, network, storage).
Некоторые транзакции требуют мало времени процессора (ничего не вычисляют), зато они могут изменить сразу несколько балансов и записать большой объем данных в хранилище (storage). Другие транзакции сильно нагружают процессор, чтобы произвести криптографические вычисления, но результатом будет единственное небольшое значение, записанное в хранилище. В первом случае больше работы достанется жесткому диску и оперативной памяти, а во втором — процессору. Эти параметры могут сильно повлиять на стоимость серверов вашего блокчейна, поэтому оценка характера транзакций — важная часть технического дизайна.
Помимо транзакций большое значение имеют сценарии работы блокчейна: какое количество каких транзакций от какого количества аккаунтов сеть обрабатывает в единицу времени. Это может быть всего десяток аккаунтов, каждый из которых отправляет много транзакций в сеть, или постоянный приток тысяч новых аккаунтов, которые заключают одну небольшую сделку. Нужно понимать, что сети для игр, финтех-приложений или криптографических протоколов сильно отличаются по характеру нагрузки на ноды.
Любая логика, сложнее чем просто перевод токенов с адреса на адрес, требует использования определенного кода (смарт-контракты, runtime и т.п.). Работая над проектом блокчейна необходимо учесть, какая виртуальная машина для исполнения такого кода будет использоваться в проекте:
Вариант 1: специализированная виртуальная машина (VM)
Примеры: EVM (Ethereum), TVM (TON)
Специализированные VM, как правило, ограничены и заточены строго под смарт-контракты своей платформы. Они порождают более предсказуемые результаты, являются наиболее безопасными и точно учитывают ресурсы, потраченные на обработку транзакций.
Вариант 2: стандартная виртуальная машина
Примеры: Web Assembly в EOS, Parity Substrate (Polkadot).
WebAssembly (WASM) — это веб-стандарт, используемый для создания кода, исполняемого на стороне клиента и более производительного, чем jаvascript. Теоретически, смарт-контракты под WASM можно писать на любом языке, но для блокчейнов лучше подходят низкоуровневые языки (C, C++, Rust и т.д.), иначе получившийся код будет плохо оптимизирован.
WASM также ведет учет потраченных на исполнение ресурсов. Имея большую функциональность контрактов, WebAssembly менее безопасна, чем специализированная виртуальная машина.
Вариант 3: обработка транзакций нативным кодом
Примеры: Hyperledger Fabric, Cosmos.
Обработка нативным кодом используется, когда код, обрабатывающий транзакцию, фактически встроен в ноду. Минус данного варианта — наименьшая безопасность и детерминированность обработки транзакций; плюс — высокая функциональность (разработчикам доступны любые функции языка без ограничений).
Еще одним из критериев выбора блокчейна является способ обновления кода контрактов. При эксплуатации системы неизбежно будут возникать ошибки и необходимость добавлять и изменять функциональность системы. В современных блокчейнах эти задачи можно решать несколькими способами.
Вариант 1: пользовательские смарт-контракты
Примеры: смарт-контракты в Ethereum, EOS, TON, Parity Substrate (с модулем пользовательских смарт-контрактов WASM или EVM).
В этой схеме любой пользователь может создать смарт-контракт или несколько, соединенных в сложную систему. Контракты можно размещать и обновлять без взаимодействия с валидаторами сети.
Эта схема — наиболее гибкая. Она позволяет строить системы контрактов произвольной сложности, но требует более сложной логики работы ноды, потому что код контрактов является недоверенным и может содержать все что угодно. Поэтому нужно, чтобы нода исполняла такой код крайне осторожно, ограничивая его по времени и запрашиваемым данным, и не позволяла бы влиять на консенсус.
Вариант 2: код runtime, контролируемый валидаторами
Примеры: runtime в Parity Substrate, Application в Cosmos.
Данную схему можно представить в виде одного большого смарт-контракта, который обрабатывает все виды транзакций. Код проверяют валидаторы и голосуют за применение изменений, после чего новая логика начинает работать. При этом разработчики избавлены от большого числа ограничений и могут создавать код runtime из набора готовых модулей.
Эта схема делает более сложным изменение кода, который обрабатывает транзакции, но позволяет не делать дополнительные проверки безопасности. Валидаторы в данной схеме обязаны проверять изменения и не пропускать уязвимый код, иначе рискуют получить неработоспособный блокчейн.
Зато разработчики такого «runtime» получают в распоряжение гораздо больше возможностей и ресурсов, чем в схеме с пользовательскими контрактами. Эта схема особенно актуальна для парачейнов (небольших дочерних цепочек с отдельным функционалом, являющимися частями большой системы из множества блокчейнов).
Без понимания характера транзакций, особенностей виртуальной машины и логики работы смарт-контрактов проект может крайне неоптимально использовать блокчейн. Например, поддерживать работу дорогостоящего ПО ради простейших операций или проводить рискованные обновления основного кода ноды ради небольших исправлений в логике.
Ограничения блокчейна
При запуске собственного блокчейна нужно оценить технические требования клиента и понять, насколько они выполнимы.
Одним из таких требований является время «исполнения» транзакции на стороне клиента. Частой ошибкой является оценка скорости только на основе tps (количество транзакций в секунду).
Разработчики, как правило, оценивают tps как количество транзакций в блоке ко времени блока. Например, под «1000 tps» имеется в виду, что время между блоками равно 1 секунде, а в блоке может быть до 1000 транзакций. Это не значит, что блокчейн обрабатывает одну транзакцию за 0.001 секунды, поскольку время обработки транзакции зависит от времени производства блока.
Если время производства блока — 3 секунды, то время обработки одной транзакции может достигать 3-х секунд (от момента отправки транзакции и до появления следующего блока). 3000 tps (при максимуме в 1000 транзакций в блоке) можно достичь только при параллельной отправке транзакций с разных аккаунтов.
Еще одно важное ограничение современных блокчейнов — это число валидаторов (серверов, производящих и подтверждающих блоки). Произведя блок, валидаторы обязательно приходят к согласию (консенсусу) относительно него. Время производства блока зависит от числа валидаторов и числа сообщений, которыми им надо обменяться. Для любого сетевого консенсуса требуется согласие минимум 1/2 N + 1 валидаторов, а с полными гарантиями безопасности — согласие 2/3 N + 1 валидаторов. Данные значения являются фундаментальными, обойти их нельзя, так как они обеспечивают устойчивость сети к злонамеренному поведению участников.
Если вы планируете запускать блокчейн, забудьте о мгновенных ответах клиентам и миллионах валидаторов. Такие масштабы достижимы только с появлением полноценных квантовых технологий связи и криптографических вычислений.
Планирование запуска и поддержки сети
Предположим, вы выбрали блокчейн и собираетесь его запускать. Каковы дальнейшие шаги?
Шаг 1: выбор имплементации, оценка трудозатрат
Прежде всего, необходимо выбрать конкретную технологию, оценить риски и трудозатраты на реализацию проекта, а также учесть ограничения конкретных решений. Решение может быть уже проверенным в реальных условиях или находиться на стадии разработки.
В случае, если вы запускаете собственноручно разработанное решение, изучите наиболее близкие аналоги. Так вы сможете сэкономить время и учесть проблемы, которые до вас уже решили другие команды.
Шаг 2: Тестовые запуски и масштабное тестирование сети
Тестирование сети — это проверка работоспособности блокчейна с числом валидаторов, приближенным к реальности. Если блокчейн подразумевает 100 валидаторов, необходимо убедиться, что сеть работоспособна под нагрузкой.
При тестировании будет подготовлена инфраструктура для автоматического разворачивания сети с несколькими валидаторами, что пригодится на последующих этапах.
Без тестирования есть серьезный риск, что сетевой консенсус содержит ошибки или уязвимости, особенно если это собственное решение, а не хорошо известный алгоритм. Собирать информацию о проблемах в уже запущенной сети будет очень непросто.
Шаг 3: Запуск тестовой сети (testnet)
Testnet нужен, чтобы пользователи и команда могли опробовать в ней то, что будет работать в основной сети (mainnet). Весь функционал основной сети должен присутствовать в тестовой, а клиентские приложения — поддерживать обе сети. Благодаря точности смарт-контрактов, тестирование рабочих продуктов можно провести с 99% точностью, с реальными балансами реальных пользователей.
В testnet можно раздать токены, проверить, как валидаторы запускают свои ноды, провести первые сделки вместе с активными пользователями, а полученные результаты позже использовать в mainnet.
Некоторое ПО необходимо будет поддерживать сразу после запуска тестовой сети (например, веб-интерфейс для валидаторов, мониторинг или обозреватель блоков). Информация, полученная на этапе запуска этих сервисов в тестовой сети, пригодится при «чистовом» запуске в mainnet.
Именно на этом этапе будет видно качество работы команды проекта — насколько стабильно запущенное ПО, насколько качественно была написана документация, насколько быстро потенциальные валидаторы смогли поднять требуемый софт, сколько раз пришлось вносить исправления и т.д.
Шаг 4: определение процедуры добавления валидаторов mainnet
Обычно в роли валидаторов сети выступают независимые компании, поэтому собрать их вместе и заставить синхронно выполнить какие-то действия почти невозможно. Все процедуры должны предусматривать произвольный порядок действий валидаторов, учитывать их географическое распределение и степень неподготовленности.
Наиболее популярный вариант выбора валидаторов на сегодняшний день — процедуры, предусмотренные алгоритмами DPoS. В этом случае владельцы токенов голосуют своими балансами за валидаторов. Топ валидаторов, набравших большинство голосов-токенов получают право производить блоки. В proof-of-authority (POA) сетях и коропоративных блокчейнах, ситуация аналогична, но вместо балансов токенов используются голоса других валидаторов.
Перед стартом основной сети нужно сформировать начальный список валидаторов и решить, в какой момент начнется полноценное производство блоков. Технически команда может сразу прописать всех валидаторов в начальных блоках сети или запустить сначала только своих валидаторов, а потом постепенно заменять их на новых.
Шаг 5: запуск основной сети
Запуск mainnet должен сопровождаться активным мониторингом. Желательно, чтобы сводная информация от всех валидаторов была представлена в одном сервисе — так команда проекта сможет более активно реагировать на проблемы в сети.
Новые требования также предъявляются к работе обозревателя блоков — главного внешнего сервиса сети. Он должен автоматически переключаться на запасные сервера в случае сбоев, так как информация о транзакциях крайне важна пользователям и команде проекта. Также может потребоваться резервное копирование, если обозреватель хранит предоставленную пользователями информацию (например, верификация кода контрактов в Etherscan).
Довольно капризным в плане поддержки на этом этапе может являться мост — ПО, которое позволяет переносить токены из одного блокчейна в другой. От его работы зависят балансы реальных пользователей, поэтому необходимо уделить особое внимание его безопасности.
Шаг 6: Поддержка и обновление кода
После запуска основной сети работа команды не прекращается, особенно если блокчейн построен на основе существующих решений. Базовый код тоже развивается, и в нем накапливаются важные исправления ошибок и оптимизации. Эти изменения необходимо переносить в проект и своевременно обновлять код блокчейн-нод.
На этом этапе очень важна разработанная документация и процедуры, которые должны были быть опробованы в тестовой сети. При обновлении кода не должно происходить накладок, потому что в этом случае валидаторы теряют деньги, время и репутацию. В mainnet может существенно меняться состав валидаторов, и в случае их недостаточной поддержки или некачественной документации это может привести к проблемам в работе сети.
Заключение
При правильном подходе запуск блокчейна на базе уже работающих решений не несет серьезных рисков. Как правило, проблемы носят экономический или организационный характер, не связанный с внутренним кодом нод.
Построенные на основе публичных сетей (Ethereum, EOS) решения являются достаточно надежным ПО, доступным пользователям интернета без ограничений. Этим свойством не могут похвастаться централизованные финансовые системы: выставить в открытый доступ банковское API или базу данных с критичной информацией без регистрации, логинов/паролей и мониторинга не представляется возможным.
Хотя разработка и запуск блокчейна довольно затратны, реальная эксплуатация может приятно удивить участников безопасностью, саморегуляцией и способностью сети сохранять работоспособность и точность исполнения транзакций в сложных условиях.
Выбираем алгоритм консенсуса
Перед разработкой собственного блокчейна ваша команда должна четко понимать, для чего необходим блокчейн и какой бюджет вы сможете выделить на его содержание.
Проектирование и запуск блокчейна имеют свои нюансы. Их можно легко упустить при планировании, если вы неверно оценили объем и сложность задачи.
Чтобы помочь проектам избежать таких ошибок, руководитель отдела исследований MixBytes Сергей Прилуцкий подготовил пошаговое руководство по запуску блокчейна.
Данная статья поможет вам определиться с выбором алгоритма консенсуса для построения собственного блокчейна, исходя из его технических свойств и ограничений (они подробно описаны в предыдущей статье).
***
Я буду исходить из того, что блокчейн предназначен для достаточно сложных сделок. Все рассматриваемые решения подходят для работы с кодом, размещенным в блокчейне.
Я намеренно не включил в перечень решения, которые находятся на ранних этапах развития, неизвестны широкому кругу программистов или не имеют важных механизмов, обеспечивающих безопасную работу блокчейна: неустойчивы к византийскому поведению нод (non-BFT) или могут быть успешно атакованы с единственного аккаунта. Без этих свойств блокчейн не имеет ценности и превращается в медленную, дорогую и неудобную в использовании базу данных.
Чтобы определиться, строить ли новую систему или использовать готовое решение, в первую очередь необходимо определиться с консенсусом — главным алгоритмом, обеспечивающим блокчейну BFT-свойства.
Консесусы: proof-of-work, proof-of-stake, proof-of-authority
Для начала рассмотрим разные типы консенсуса с точки зрения запуска и эксплуатации сети. Любой BFT-консенсус в блокчейнах должен удовлетворять как минимум два важных свойства распределенных систем: safety и liveness.
Safety гарантирует, что алгоритм никогда не придет к неверному консенсусу, если большинство узлов честно следуют протоколу, а liveness — что алгоритм никогда не «застрянет», не имея возможности выбора пути.
Эти свойства должны гарантированно выполняться при наличии в сети byzantine-участников, намеренно действующих наихудшим образом.
Proof-of-work (PoW)
Преимущество этого типа консенсуса — отсутствие необходимости регистрировать в сети валидаторов. Принимается любой блок, удовлетворяющий требования, без подтверждения других участников. Это позволяет оставить лишь часть логики, отвечающую за изменение сложности майнинга.
В теории этот вид консенсуса допускает любое число валидаторов — ведь соревноваться за блок может сколько угодно валидаторов. В реальных сетях, если валидаторов (майнеров) много, а сложность сети высока, то шансов получить награду за блок у отдельного майнера крайне мало. Для такого консенсуса необходимо сразу планировать работу майнинговых пулов, объединяющих майнинговые мощности, и соответствующее ПО.
При старте сети валидаторы должны сразу же установить серьезные вычислительные мощности. Это часто упускают из вида, надеясь на постепенное увеличение сложности сети и количества майнеров. Невысокий хешрейт открывает двери для недорогих атак 51%, когда атакующий на очень короткое время арендует много серверов, чтобы получить 51% хешрейта сети, и проводит атаку двойной траты.
Поэтому для PoW-сети придется планировать более сложную процедуру запуска. Сначала команда запускает сеть с собственными валидаторами, а потом постепенно «уступает» производство блоков майнерам, которые в этом случае могут плавно наращивать мощности.
Proof-of-authority (PoA)
PoA-консенсусы — это алгоритмы, использующие заранее назначенный набор аккаунтов, которые могут производить блоки и голосовать за принятие и исключение новых членов. Этот вид консенсуса — естественный выбор для корпоративных блокчейнов и тестовых сетей. Здесь может вообще не быть внутреннего токена, а при голосованиях за блоки и при выборах валидаторов 1 валидатор = 1 голос.
Это семейство алгоритмов представлено фундаментальным алгоритмом pBFT. В измененном виде он является базой для большого числа консенсусов, позволяя договориться о любых данных со всеми гарантиями безопасности.
В предыдущей статье я уже говорил о том, что не существует гарантированно безопасных консенсусов, в которых требуется менее, чем 2/3 + 1 сообщений от валидаторов. pBFT это доказывает математически. В разных консенсусах эти сообщения, подтверждающие, что валидатор принимает блок, собираются в разные моменты времени.
Процесс сбора подтверждений и в дальнейшем признание блока окончательным получил отдельное название финализации. Блоки, на которых достигнут общий консенсус называются финальными. Для уменьшения числа сообщений в части алгоритмов финальность достигается не на всех блоках, а только на некоторых, «заверяющих» сразу несколько блоков. Таким образом сильно уменьшается число сообщений между валидаторами и существенно ускоряется консенсус.
Из-за разделения процедур валидации блоков и финализации присутствует некоторая путаница, из-за которой оценивать скорость консенсуса становится непросто.
Например, алгоритм pBFT, используемый в консенсусе Tendermint (Cosmos), требует консенсуса на каждый блок, т.е. мгновенно финализирует его, а алгоритм EOS финализирует лишь один из множества блоков, финализируя сразу цепочку.
Aura — популярный алгоритм для POA-сетей на базе Ethereum — использует псевдослучайный выбор валидатора для каждого блока и параллельно договаривается о финализированных блоках с использованием алгоритма GRANDPA, ожидая > 2/3 подписей-подтверждений от других валидаторов. Такой параллельно работающий алгоритм финализации получил название finality gadget.
Похожим образом работает консенсус EOS, создающий «расписание» для валидаторов на некоторый период времени (epoch) и требуя финализации блоков в конце каждой epoch.
Proof-of-stake (PoS)
Почти все существующие реализации этих алгоритмов включают в себя алгоритмы из POA-консенсусов, что добавляет путаницы. Современные PoS-алгоритмы работают следующим образом: при помощи балансов участвующих в выборах валидаторов (стейков) формируется список валидаторов (например, голосованиями, заморозкой депозитов и т.д.). В течение некоторого времени, до момента изменения списка валидаторов, сеть работает, используя PoA-алгоритм, например pBFT.
Наиболее распространенными стали алгоритмы, названные Delegated Proof-of-Stake (DPoS), где аккаунты в сети различными способами голосуют своими балансами за валидаторов, формируя топ из N валидаторов.
Выбирая консенсус для своего блокчейна, стоит в первую очередь рассмотреть процесс финализации блоков. От нее будет зависеть время, через которое клиент получит подтверждение своих транзакций. Токеномику, процедуру «выборов» валидаторов и получение наград за блоки лучше рассматривать отдельно. В этой части может быть применено большое число разных экономических механизмов.
Отмечу, что корпоративным сетям не стоит пренебрегать экономическими механизмами и PoS-алгоритмами, даже если в сети нет никакой экономики и токена. Любые бесплатные транзакции — это почти всегда вектор атаки на систему с единственного аккаунта. Наличие баланса «технического» токена на аккаунте может служить удобным ограничителем, когда у атакующего просто не хватит средств на полномасштабную атаку, а также позволит более гибко регулировать доступ и нагрузку на сеть.
Варианты имплементации
Планируя свой блокчейн, надо понять, можно ли использовать готовое решение или стоит создать все с нуля, полностью контролируя код.
Блокчейн — это мир открытого ПО. Закрытый код в нем практически невозможен — криптографические протоколы давно создаются на открытых международных конкурсах, а реализациям с закрытым кодом мало кто доверяет из-за больших рисков.
Используйте то, что создали программисты до вас. Крайне велика вероятность, что ваши задачи уже решали, обсуждали и проверяли, поэтому не стоит тратить на них лишние усилия.
Если же вы решили делать свой консенсус, связанный с сетевым взаимодействием, или вы используете новые криптографические концепции, которые архитектурно не укладываются в традиционный дизайн блокчейнов; если вы собираетесь обойти все существующие решения по производительности, экономя каждый бит; если транзакции в вашем блокчейне настолько специфические, что ничего подобного в мире не существует… Тогда ваш путь — блокчейн с нуля.
Выбираем движок
Перед разработкой собственного блокчейна ваша команда должна четко понимать, для чего необходим блокчейн и какой бюджет вы сможете выделить на его содержание.
Проектирование и запуск блокчейна имеют свои нюансы. Их можно легко упустить при планировании, если вы неверно оценили объем и сложность задачи.
Чтобы помочь проектам избежать таких ошибок, руководитель отдела исследований MixBytes Сергей Прилуцкий подготовил пошаговое руководство по запуску блокчейна.
Данная статья поможет вам определиться с выбором движка для построения собственного блокчейна.
Блокчейн с нуля
Попытки создать блокчейн с нуля без сомнения похвальны, ведь благодаря им появились многие существующие решения. Тем не менее нужно трезво оценивать возможности своей команды.
Написание с нуля кода блокчейн-ноды напоминает создание собственной базы данных с механизмом надежной сетевой репликации. Если вы поищете, сколько таких БД было создано за последние десятилетия, то найдете максимум сотню проектов. Огромной долей рынка владеют всего несколько компаний (Oracle, MS SQL Server, MySQL, PostgreSQL), а разработчики ядра таких систем ценятся крайне высоко.
Для разработки блокчейн-ноды вам придется собрать команду очень крутых и редких специалистов, имеющих опыт работы с многопоточным программированием, криптографией, сетевыми протоколами, сложными внутренними алгоритмами и понимающих работу современных операционных систем.
Особенное место для блокчейнов занимает тестирование, так как алгоритмы консенсуса могут прекрасно себя вести на нескольких валидаторах и совершенно по другому при наличии десятков и сотен узлов под нагрузкой. Увеличение числа разработчиков в данном случае приведет разве что к усложнению коммуникаций внутри команды.
По опыту нашей компании, бизнес-заказчики редко выбирают этот путь. Создание своего блокчейна — это задача для группы исследователей, энтузиастов, которые могут себе позволить работать свободно, не имея жестких сроков и бизнес-плана. Такая команда должна иметь возможность свободно исследовать любой встретившийся вопрос, не сильно заботясь о сроках сдачи проектов. На текущий момент работа над такими проектами, как биткоин и Ethereum, производится независимыми разработчиками по всему миру, без жестких дедлайнов. Внешнее давление бизнес-факторов может сыграть с вашим проектом злую шутку, заставив быстрее решать проблемы, не продумав последствия.
Готовые блокчейн-движки
Я намеренно назвал раздел «движки», так как этот термин в области ПО часто используется для обозначения комплексов разнопланового ПО, предназначенного для решения конкретной задачи. Например, «поисковый движок» или «графический движок» — это не только код, но и вспомогательное ПО, дополнительные утилиты, описания алгоритмов и многое другое. Учитывая существование нескольких основных ядер блокчейнов, на базе которых построены уже существующие сети, будет удобно называть их движками (например, «построен на движке Ethereum»).
Если ваш блокчейн не обладает уникальной архитектурой и ваша задача — доставка решения за определенный промежуток времени, лучшим вариантом будет работа с уже существующими движками. Они позволяют реализовать ваш вид консенсуса и транзакций, по-своему организовать управление валидаторами сети. Вы сможете использовать готовый открытый код, проверенный в реальных сетях. Вам не придется изменять код блокчейн-ноды, а для реализации своей логики нужно будет менять только часть, предусмотренную разработчиками движков. Не внося новых уязвимостей и не решая проблемы сетевого слоя, вы сможете сосредоточиться только на бизнес-логике вашего блокчейна.
Разберем готовые для работы блокчейн-движки, используя которые вы сможете запустить собственный блокчейн, спроектировать и реализовать его внутреннюю экономику и организовать запуск для проведения сложных сделок.
Ethereum
Этот комплекс ПО построен на базе ядра публичного блокчейна Ethereum. Публичный Ethereum использует консенсус типа Proof-of-Work, а его многочисленные тестовые сети — различные виды Proof-of-Authority и Proof-of-Stake консенсусов. ПО отвечает самым строгим критериям безопасности, проверено в десятках реально работающих сетей и, на мой взгляд, является наиболее развитым для создания блокчейнов с любыми видами консенсусов и полноценными, многофункциональными смарт-контрактами.
Нужно отметить роль проекта POA Network, чьи разработчики проделали огромную работу и запустили уже несколько быстрых и надежных сетей. POA Network существенно быстрее оригинального Ethereum, но при этом обладает той же стойкостью и универсальностью для заключения любых сделок, а роль валидаторов (майнеров) исполняют компьютеры, честная работа которых заверяется юридически. Эту сеть можно считать эталоном для запуска корпоративных блокчейнов на базе Ethereum.
Код блокчейн-ноды и консенсус
Существуют две основных имплементации кода ноды Ethereum: на языке Rust (код, названия: poa-parity (старое) или openethereum(новое)) и на Go (код, название: geth).
На момент написания при построении PoA-сети на geth (Go) вам будет доступен только консенсус Clique — это простейший и небезопасный протокол без финализации, который можно использовать только в тестовых целях.
Консенсус, реализованный в poa-parity (Rust), состоит из двух алгоритмов: schedule валидаторов Aura и finality gadget GRANDPA. Именно этот вариант, проверенный и безопасный, работает в POA-сетях на базе Ethereum. POA Network работают также над имплементацией перспективного BFT-консенсуса HoneyBadger.
Отдельного упоминания заслуживает новая блокчейн-нода Nethermind, написанная на C# для платформы .NET Core. Она полностью поддерживает Ethereum, большое число операционных систем и является отличным выбором для компаний, которые используют .NET Core.
Смарт-контракты и управление сетью
POA Ethereum использует виртуальную машину EVM и смарт-контракты, которые лучше всего писать на языке Solidity. EVM давно стала стандартом для виртуальных машин с большим количеством готового кода и паттернов разработки. Код контрактов под EVM отвечает за большие суммы криптовалюты, и любая найденная уязвимость вызывает мощную реакцию сообщества и СМИ, поэтому безопасность контрактов EVM на текущий момент крайне высока.
Управление списком валидаторов осуществляется посредством смарт-контрактов — это потрясающе удобно. Можно оперировать одним или несколькими токенами или вообще избавиться от них. Можно сделать процедуру добавления валидаторов гибкой или максимально упростить, добавив «всемогущий» аккаунт. Мощь этой схемы в том, что буквально один разработчик контрактов может создать полную экономику сети на одной платформе с высочайшим уровнем безопасности и переносимости, реализовав сразу и управление сетью, и логику сделок, и другие свойства.
Дополнительное ПО
С Ethereum можно использовать jаvascript-библиотеку web3.js, вне зависимости от консенсуса, валидаторов и ее расположения.
Для POA Ethereum существует репозитарий для автоматизации операций по развертыванию готовой сети — deployment-playbooks.
Если вы планируете запускать POA Ethereum, используйте эту инструкцию. Она проведет вас от создания ключей валидаторов к запуску первых нод, развертыванию системных контрактов и запуску интерфейса валидаторов и обозревателя блоков.
Готовая POA-сеть Ethereum присутствует в AWS, но я все же рекомендую контролировать запуск своими руками. Вы должны понимать, какие сервисы вы запускаете и как они работают.
EOS и его форки
Вторым по гарантиям работоспособности и безопасности будет EOS. “OS” в его названии появилась не случайно.
EOS можно запустить в качестве отдельной сети, в PoS- или PoA-варианте. Как и Ethereum, это ПО уже проверено в бою, обладает высокой безопасностью и функционалом, который позволяет запустить собственный блокчейн со смарт-контрактами для автоматизации любых сделок
Если Ethereum имеет простую систему адресов, то в EOS сразу же используется иерархическая система аккаунтов и права на различные действия. Все это делает EOS похожей по дизайну на операционную систему — «программу для запуска других программ».
В качестве межкорпоративной платформы EOS позволяет из коробки получить удобную систему управления аккаунтами и быстрый консенсус, а также легко интегрировать практически любой функционал при помощи плагинов на C++ и смарт-контрактов на C++/WebAssembly (например, можно добавить другую криптографию).
Дизайн консенсуса в EOS и быстрые блоки позволяют достичь очень быстрого времени ответа пользователю, что крайне важно для построения децентрализованных приложений со сложным функционалом (например, проекты Cyberway, Golos.io или соцсеть Commun). Cyberway недавно произвел сложнейшую миграцию всей бизнес-логики из предыдущего блокчейна прозрачно для пользователей, что лишний раз доказывает гибкость и универсальность EOS.
Код блокчейн-ноды и консенсус
Код EOS написан на C++ и развивался на основе опыта, полученного разработчиками при работе над движками Graphene, Bitshares, Steemit. Используется собственный вариант DPoS-консенсуса.
Сейчас почти все проекты, использующие DPoS, строят свои алгоритмы очень похожим на EOS образом: это аккаунты, «голосующие» балансом токена за топ валидаторов. Валидаторы подписывают блоки по одиночке, но каждый в назначенный квант времени, согласно расписанию. Затем они коллективно фиксируют так называемый Last Irreversible Block (LIB), на котором собирается 2/3 + 1 подписей от валидаторов.
Многие форки EOS пытаются улучшить это консенсус. Например, наш вариант Haya использует для фиксации LIB другой finality gadget — RANDPA, чтобы достичь времени финальности в 2-3 секунды.
Переход к корпоративному POA-консенсусу не вызывает затруднений, так как список валидаторов управляется системными смарт-контрактами.
Смарт-контракты и управление сетью
Смарт-контракты в EOS используют модифицированную виртуальную машину WebAssembly, обычно пишутся на языке C++ и могут создаваться и использоваться любым аккаунтом. Писать смарт-контракты не сложно, во многом они перекликаются с Solidity.
В EOS, как и в POA Ethereum, управление сетью, основной токен (или токены) и типы транзакций можно реализовать в системных смарт-контрактаx (вот, например, системный токен). Интересной особенностью контрактов EOS является использование абстракции table для хранения данных контракта. В Ethereum в основном используется mapping (ассоциативный массив).
Еще одна особенность смарт-контрактов в EOS — upgradeability. Владелец контракта может заменить его, обновив логику или исправив ошибку. Это сильно отличается от Ethereum, где неизменность контрактов — важное условие, гарантирующее, что логика контракта никогда уже не будет изменена, если не произойдет хардфорк.
Для межкорпоративных блокчейнов, на мой взгляд, возможность изменять код контрактов — важное преимущество. Незаметно что-то украсть здесь все равно не получится, зато обновить код по соглашению сторон можно без всякого участия валидаторов.
В EOS возможно организовать «спонсорские» транзакции, оплачиваемые владельцами контракта, а не самими пользователями. Это мощнейшая возможность для привлечения новых пользователей. Вы ведь помните, что «бесплатных» транзакций без потери безопасности в блокчейнах не бывает?
Дополнительное ПО
BOSCore, Telos, Haya и еще десяток форков EOS доказывают, что это ПО интересно большому количеству проектов. Для EOS существует достаточно инструментов, и вам не придется с нуля реализовывать сопутствующее ПО.
Eosjs — аналог web3.js, позволяет работать с контрактами любой сети на базе EOS из браузера и любых приложений.
EOSTracker — обозреватель блоков с открытым кодом и децентрализованными приложениями для голосований за валидаторов.
У EOS нет одного большого и мощного интегратора, как POA Network для Ethereum, поэтому каждый проект строит собственное решение. Тем не менее, основной код ноды стабилен и работает под серьезными нагрузками без сбоев.
Parity Substrate
Substrate создается командой компании Parity. Разработано огромное количество ПО: кошельки, блокчейн-ноды, системы смарт-контрактов, компиляторы, виртуальные машины.
Parity Substrate позволяет разработчику достаточно легко создать свой вариант блокчейна из готовых модулей со сложным консенсусом и логикой обработки транзакций. Substrate — это конструктор блокчейнов, на котором, к примеру, можно сделать блокчейн-ноду Ethereum или биткоина.
Substrate — это часть крупного проекта Polkadot — системы, состоящей из основной цепочки и множества цепочек-шардов с индивидуальной логикой.
Преимущество «подключения» своего блокчейна к Polkadot заключается в возможности ончейн-обмена данными с другими цепочками и возможностью использовать их контракты, аккаунты, токены без дополнительного ПО.
Код блокчейн-ноды и консенсус
Код Substrate написан на языке Rust. На мой взгляд, в структуре Substrate чувствуется большой опыт команды по созданию блокчейнов, так как все компоненты отлично структурированы, разделены на отдельные модули, а в коде присутствуют подробные комментарии. Доказательством гибкости этого движка является существование клиента для сети биткоина и ZCash на основе кода Substrate.
Что касается консенсуса, то можно выбрать из нескольких готовых вариантов или написать свой собственный. В большинстве случаев это PoA или DPoS, что в случае Substrate означает использование алгоритма Aura и GRANDPA.
Производительность блокчейнов на базе Substrate высока. Основная цепочка Polkadot была протестирована нами в конфигурации с 99 валидаторами, распределенными по трем континентам, и показала отличные результаты.
Преимуществом Substrate я считаю продуманность архитектуры, стек разработки (Rust), и огромное поле для развития. Это крайне гибкая сеть, на базе которой можно построить решения любого уровня сложности.
Смарт-контракты и управление сетью
Substrate, в отличие от Ethereum и EOS, обрабатывает транзакции при помощи кода, который размещается валидаторами, а не пользователями. Это код называется “runtime” и исполняется виртуальной машиной WebAssembly.
Напомню, что runtime — это по сути один большой смарт-контракт, который обновляется валидаторами и собирается разработчиком из отдельных модулей. Модули содержат логику аккаунтов, токенов, сделок любой сложности, и т.д. Именно это свойство превращает Substrate в конструктор. Вполне возможно, для решения ваших задач потребуется просто скомбинировать несколько готовых модулей или незначительно доработать один из них.
Особого упоминания заслуживают модули пользовательских смарт контрактов: WASM и EVM. Они дают возможность пользователям размещать свои смарт-контракты, поэтому запуск универсального блокчейна на Substrate тоже возможен.
Ограничения на запуск транзакций реализуются разработчиками runtime — можно сделать все транзакции за одну и ту же цену, учитывать ресурсы с точностью до бита или сделать все бесплатным и вообще не использовать внутреннюю криптовалюту.
В плане гибкости у runtime есть множество преимуществ — разработчик может комбинировать их, создавать сложные роли, объединять управление сетью, внутреннюю логику и экономику. Учитывать следует лишь то, что обновление кода runtime проводится кворумом валидаторов.
Дополнительное ПО
Для Substrate есть ряд полезных решений: polkascan — обозреватель блоков и комплекс программ на JS для работы с Polkadot и сетями на базе Substrate. Возможно, вам пригодятся ansible-сценарии для развертывания готового кластера на базе Substrate, который мы использовали для тестирования Polkadot.
У Substrate нет богатого выбора универсального ПО, кошельков и обозревателей блоков, как у Ethereum или EOS, так как цепочки могут сильно отличаться между собой. Проект активно развивается, и множество команд параллельно создают сопутствующее ПО.
Cosmos SDK
Cosmos — это проект на базе одной основной цепочки и множества дочерних блокчейнов, называемых «zones». Дочерние цепочки строятся на основе Cosmos SDK — набора ПО для построения блокчейнов.
Cosmos — это продолжение проекта Tendermint, из которого ключевыми технологиями является надежный консенсус и концепция Application, сходная с runtime в Substrate.
Как и в случае Polkadot+Substrate, блокчейн, созданный с помощью Cosmos SDK, может жить отдельно или подключиться к экосистеме
Cosmos как дочерняя цепочка.
Весь комплекс ПО Cosmos написан на Go и отлично структурирован и активно используется. На его основе уже работают несколько проектов, среди которых Binance Chain.
Если ваши разработчики пишут на Go — Cosmos SDK может вам подойти. Он работает и активно развивается в реальных проектах, чьи блокчейны и транзакции можно увидеть в публичных сетях.
Код блокчейн-ноды и консенсус
Главная концепция Cosmos называется Application. Любой блокчейн представляет собой машину состояний, и в Cosmos она вынесена в отдельную часть кода.
По сути, разработчик просто задает правила, по которым одни данные превращаются в другие при внешнем воздействии, программируя так называемую функцию state transition. Это сложно звучит, но по факту обработка транзакции — это state transition, которая меняет несколько балансов. Именно этим занимается Application — принимает некоторое воздействие извне (транзакцию) и меняет свое состояние (state). Получившиеся изменения фиксируются в блокчейне. При этом разработчик не должен решать проблемы консенсуса и сети — сеть сама договорится между собой и придет к консенсусу относительно результатов.
Консенсус в Cosmos построен на базе консенсуса Tendermint, крайне близкого к pBFT. Его особенность в том, что подтверждения валидаторов собираются на каждый блок, что означает мгновенную финальность, как только блок принят сетью. Этот алгоритм требует много сообщений между валидаторами, и в случае проблем с сетью этот консенсус будет медленнее финализировать цепочку.
Зато он является наиболее предсказуемым, защищенным от форков, имеет формальные математические доказательства надежности и, по моему мнению, является наиболее строгим и безопасным решением из всех существующих консенсусов.
Смарт-контракты и управление сетью
Application в Cosmos можно рассматривать как единый смарт-контракт, ответственный за обработку всех видов транзакций. Вот пример структуры Application для сервиса регистрации имен.
Одновременно с созданием кода для блокчейн-нод, Cosmos SDK создает код клиента, который умеет формировать транзакции нужных типов.
Для ограничения транзакций в Cosmos, как в Ethereum, используется газ. Исполняя транзакцию, валидаторы вычисляют ее стоимость в условных единицах «gas». Отправляя транзакцию, пользователь указывает цену, которую он готов платить за единицу газа и лимит, который он готов потратить. Это является основанием для вычисления цены за транзакцию.
Важным для Application в Cosmos являются требования к детерминизму кода, т.е. разрабатываемые операции не должны порождать разные результаты в разные моменты времени или на разных архитектурах, иначе блокчейн не будет работать.
Дополнительное ПО
Параллельно с созданием кода Application, Cosmos SDK позволяет сразу же получить код, который вызывает нужные функции с клиентских машин. Этот код можно использовать на сайте, работающем с Cosmos, или в кошельке (клиенте) сети.
На jаvascript я нашел несколько полезных библиотек: js-cosmos, cosmosjs и универсальную js-abci, реализующую интерфейс ABCI. Их удобно использовать, если взаимодействие с вашим блокчейном планируется из браузера. ABCI позволяет создавать Application на разных языках, среди которых Java, C++, Python. Проект lotion, например, позволяет создать блокчейн полностью на jаvascript.
Cosmos бурно развивается, на этом движке запускается много разных проектов. Рекомендую обратить на него внимание, если у вас есть экспертиза в Go и вы хотите надежное работающее решение.
Поднимаем тестовую сеть и оцениваем производительность
Перед запуском основной сети необходимо убедиться в бесперебойности и устойчивости к специфичным атакам. В противном случае исправление допущенных ошибок в децентрализованной среде может обойтись очень дорого.
Чтобы помочь проектам избежать таких ошибок, руководитель отдела исследований MixBytes Сергей Прилуцкий подготовил пошаговое руководство по запуску тестнета и оценки его производительности.
Итак, вы выбрали блокчейн-движок и реализовали первую версию собственного блокчейна. Теперь, чтобы проверить стабильность сети при изменениях, потребуется полномасштабное тестирование. А чтобы будущие пользователи и валидаторы смогли заранее подготовить свои сервисы к реальным условиям, требуется тестовая сеть (или testnet) — максимально полная копия основной сети.
Без тестнета вы не сможете качественно проверить разрабатываемый код, а пользователи не смогут попробовать ваши сервисы в “лабораторных” условиях.
Тестирование и мониторинг блокчейна
Я уже неоднократно писал про тестирование блокчейнов (читайте здесь и здесь), поэтому предлагаю сосредоточиться на практических вопросах. При работе блокчейна в основной сети вы можете столкнуться со множеством проблем, которые стоит решить заранее. Приведу несколько примеров возможных технических проблем:
блокчейн оперирует транзакциями, сохраняющими довольно объемные данные. Запуск и поддержка ноды могут потребовать слишком много места на диске, а стоимость владения нодой для валидаторов быть очень высокой.
вы все правильно оценили, эффективно сжали данные транзакций, и на тестовых машинах разработчиков рост блокчейна стал удовлетворительным. Однако сжатие данных потребовало от нод много ресурсов процессора, что сильно замедлило общую производительность сети.
вы нашли оптимальный баланс между размером и сложностью обработки транзакций, и блокчейн отлично работает на машинах разработчиков. Однако между ними локальная сеть, и после ее запуска в глобальной сети блоки стали передаваться медленно, а скорость сети сильно снизилась.
вы оптимизировали сеть за счет более эффективного консенсуса, но теперь финализация блоков стала отставать.
Продолжать можно бесконечно. И это только верхушка айсберга — ведь еще есть экономические и организационные проблемы. Многие из них можно решить за счет грамотного проектирования и подбора алгоритмов, но лучше использовать комплексный подход.
Поскольку каждая строчка кода исполняется на десятках серверов, даже небольшие изменения могут вызвать каскад последствий и ошибок. Чтобы избежать их, необходимо регулярное тестирование, активный мониторинг и правильная организация работы команды проекта.
Мониторинг
Практически во всех современных блокчейнах предусмотрена возможность подключения внешнего мониторинга для своевременного выявления ошибок. Это не только система уведомлений, сообщающая о критических проблемах, но и сбор важных метрик с нод. Задача системы сбора метрик — проинформировать вас о резких изменениях в одном из компонентов и помочь быстрее найти причину деградации сети.
Необходимо отслеживать как стандартные системные параметры (загрузку процессора и жесткого диска, объем потребляемой оперативной памяти, сетевой трафик), так и специфичные метрики (консенсуса и логики процессинга).
Если вы вносите изменения в сетевой консенсус, то важными метриками будут те, что относятся к его внутренней логике. Для finalitу gadget важно, насколько последний финализированный блок отстал от последних блоков цепочки. Если изменяется сетевой p2p-слой, то полезной метрикой может быть количество активных пиров (peers — равноправные участники сети). Для сложных транзакций можно измерять время и ресурсы, необходимые для того, чтобы упаковать их в блок.
К сожалению, универсального набора метрик не существует. Обязательно добавляйте в мониторинг метрики (например, время процессинга транзакций, или отставание последнего финализированного блока), позволяющие увидеть проблемы в компонентах — так вы сэкономите время и вовремя заметите ошибки. Сделать это несложно, так как во всех современных блокчейн-движках можно отправлять данные на мониторинговые сервера (обычно это комплекс Prometheus + Grafana). Для добавления новой метрики просто скопируйте пару строчек кода.
У вас есть продакт-менеджер, который отвечает за развитие проекта? В случае разработки консенсуса или большой системы контрактов ему довольно сложно отслеживать и оценивать результаты. Зато он может взглянуть на график времени, которое ожидал клиент, пока его транзакция попадет в блок. Мониторинг, метрики и разноцветные графики — это не капризы перфекционистов, а необходимые инструменты для оценки развития проекта. Позаботьтесь о них заранее — облегчите работу коллегам.
Тестирование
С точки зрения тестирования, блокчейны выглядят как базы данных с механизмом репликации типа master-master. Для тестирования распределенных БД существует набор инструкций бенчмарков. Например, TPC или YCSB используют при тестировании новых алгоритмов репликации.
Подобных стандартов для блокчейнов пока не существует. В блокчейне возможно изменить число валидаторов при получении нескольких транзакций (добавить новых или исключить старых). Как я уже говорил, блокчейны — это сети, которые должны оставаться работоспособными при массированных атаках и сговорах, даже если часть валидаторов будет отключена или захвачена атакующими.
Чтобы проверить устойчивость сети под нагрузкой, необходимо запускать тест каждый раз после внесения изменений в консенсус или логику основных транзакций. Например, если в транзакцию добавились новые объемные метаданные или использовался новый алгоритм. При этом важна повторяемость теста — недостаточно просто запустить небольшую тестовую сеть, обновить код на нодах и запустить скрипт, отправляющий транзакции. Без воспроизведения всех начальных условий в тест будут вмешиваться внешние факторы. Хороший пример — дисковый кэш. В первом тесте данные будут считываться и записываться на диск с одной скоростью, а во второй — гораздо быстрее, и вы можете ошибочно принять это ускорение за улучшение производительности блокчейна.
Подбор последовательностей транзакций для теста тоже важен. Например, 1000 транзакций, переводящих некоторую сумму токенов между 2-мя аккаунтами — совсем не то же самое, что транзакции, переводящие токены между 1000 разными аккаунтами. Последние порождают разное поведение памяти, диска и процессора на нодах. Для хороших результатов тестов паттерн должен быть таким, чтобы система могла минимально «помочь» ускорить его в уязвимых местах. Для тестирования платежных транзакций разумно использовать N случайных аккаунтов (каждый раз новых) и транзакции, переводящие случайные количества токенов, а для хранения файлов — файлы со случайным содержимым.
Для блокчейнов и смарт-контрактов лучше всего подходит парадигма «разработки через тестирование» (Test Driven Development или TDD), которая подразумевает постоянное добавление новых сценариев тестирования, и принятие кода только, если он успешно проходит их все. Сценариев взаимодействия — множество, и незначительная ошибка в одном из них может привести к плохим последствиям в другом. Также TDD с первых дней заставит вас заниматься автоматизацией разворачивания блокчейна и сэкономит много времени на последующих этапах.
Автоматизация развертывания тестовой сети
Автоматизация запуска блокчейна «с нуля» позволяет разработчикам и команде проекта:
экономить время на разработку консенсуса.
не тратить время на запуск собственного тестового окружения.
вовремя замечать изменение, «сломавшее» что-то в другой части блокчейна.
проще воспроизводить ошибки, которые повторяются только в специфических условиях.
использовать разработанные сценарии для работы с серверами основной сети в будущем.
Разворачивание блокчейна не сильно отличается от сценариев запуска кластера БД, и местами может быть даже проще благодаря peer-to-peer сети. Вот часть сценариев по развертыванию тестовой сети Polkadot с boot-нодой для массивных тестов производительности сети на основе движка Parity Substrate. Такие же сценарии для тестирования движка Haya сэкономили нам огромное количество времени на запуск сети.
Сценарии для развертывания валидаторов могут требовать жестко прописать peer-id всех валидаторов. Таким образом они никогда не исключат друг друга из списков и в случае проблем с сетью просто дождутся восстановления подключения к сети.
Автоматическое создание аккаунтов
Эту процедуру можно начать на ранних этапах тестирования. В блокчейне потребуется стартовый аккаунт, чтобы с него раздать балансы для тестов, выделить ресурсы или провести процедуры конфигурирования. Обычно для этих задач используются аккаунты самих валидаторов.
Автоматизируя такие задачи, вы неизбежно столкнетесь с необходимостью отправлять в публичные репозитории адреса и приватные ключи валидаторов и тестовых аккаунтов. В этом нет ничего страшного, это даже удобно — ваш менеджер по продукту сможет использовать и показывать инвесторам один и тот же работоспособный кошелек, а все сценарии тестов смогут использовать готовые аккаунты.
Запуск и эксплуатация тестовой сети
Наступает важнейший этап запуска тестовой сети. Проект доказывает, что код работоспособен, сеть может долгое время существовать без остановок, и кто угодно может ее использовать. Этим блокчейны сильно отличаются от централизованных систем — с этого момента скрыть ошибки и недочеты будет сложно.
Для проектов, которые пишут собственный блокчейн без использования существующих движков, запуск тестнета — событие более важное, чем запуск основной сети. Если до этого можно было легко «обнулить» блокчейн и начать с первого блока, то, когда в testnet уже работает часть сервисов, которые изучают тестировщики, аудиторы, внешние команды, это крайне нежелательно.
Для удобного запуска имеет смысл иметь одну или несколько boot-нод с публичными фиксированными адресами. Новые ноды не будут искать в сети ноды тестнета, а обратятся по фиксированным адресам, получат актуальный список пиров и смогут быстро синхронизироваться с сетью. Задача поддержания актуальных boot-нод лежит на команде проекта.
При работе testnet возможен сценарий replay — транзакции «перепроигрываются» всеми нодами, начиная с генезис-блока. Это необходимо, если произошли изменения в логике обработки транзакций и необходимо перестроить состояние всех нод с самого начала, не потеряв транзакции пользователей. В случае критических ошибок этот сценарий возможен и в основной сети, поэтому стоит отладить его в тестовой.
Иногда тестовая сеть может требовать даже большего внимания devops, чем основная. В мейннете проект может держать только одного-двух валидаторов и следить за вспомогательными сервисами. В testnet может потребоваться обновление большого количества нод. В этот момент вам пригодится вся ранее созданная автоматизация обновления ПО.
Запуск testnet также могут провести команды, планирующие строить решения под ваш блокчейн и быть валидаторами вашей сети. Это идеальный вариант, потому что переход от тестовой сети к mainnet будет наиболее простым, без неприятных сюрпризов. Удачи с запуском!
Проводим игру валидаторов
Перед разработкой собственного блокчейна ваша команда должна четко понимать, для чего необходим блокчейн и какой бюджет вы сможете выделить на его содержание.
Проектирование и запуск блокчейна имеют свои нюансы. Их можно легко упустить при планировании, если вы неверно оценили объем и сложность задачи.
Чтобы помочь проектам избежать таких ошибок, руководитель отдела исследований MixBytes Сергей Прилуцкий подготовил пошаговое руководство по запуску блокчейна.
В некоторых блокчейнах валидаторы определены заранее, в других нодами могут владеть независимые люди и компании. Данная статья поможет вам правильно выбрать валидаторов для проекта.
Задачи валидаторов
Валидаторы — главная опора и поддержка вашей сети. Они отвечают за безопасность, и любая атака на блокчейн — это в первую очередь атака на валидаторов. Конечно, вы хотели бы видеть среди них не случайных людей, а специалистов, которые в случае проблем с сетью смогут разобраться в причинах, защитить ноды от атаки, быстро обновить код и помочь разработчикам.
Часто от нового проекта ожидают такое качество документации и поддержки, чтобы любой новичок мог стать валидатором, прочитав инструкцию README на Github. Это хорошо для децентрализации, но плохо для запуска стабильной и качественной сети. Лучше три профессиональных девопса, чем сотня новичков, которые потратят время разработчиков или бросят запуск на полпути. Со временем проект обязательно дорастет до уровня, когда любой сможет легко запустить ноду и стать валидатором.
На этом этапе особенно важно найти хороших валидаторов. А хороший валидатор должен:
уметь собрать и запустить ноду вашего проекта;
уметь оценивать нагрузку на ноду, определять проблемы с производительностью и информировать разработчиков;
уметь закрыть ноду от атаки, вывести ее из-под удара и запустить снова;
иметь автоматические средства мониторинга для решения проблем в режиме 24/7;
вовремя включаться в вопросы управления сетью, оперативно исключать зловредных валидаторов;
быстро обновлять код в случае фикса ошибок;
иметь в запасе готовые сценарии действий в случае типовых проблем.
Поддержка нод аналогична поддержке серверов высоконагруженных сервисов, которые проверяют при помощи нагрузочных тестов и пентестинга. Но имеются и свои нюансы: требуется постоянный мониторинг адресов и балансов валидатора, автоматизированные участия в голосованиях и т.п.
Для успешного запуска сети вам понадобятся несколько десятков опытных девопсов или талантливых новичков, которые смогут самостоятельно запустить ноды и поддерживать их в случае проблем с кодом или внешних атак.
Для этого есть отличная идея, о которой мы узнали от проекта Cosmos: провести игру-соревнование между потенциальными валидаторами, в которой проверяются все вышеописанные навыки.
Игра валидаторов
У специалистов по безопасности есть соревнование, которое называется “Capture The Flag”: команды атакуют сервера друг друга, пытаясь раздобыть секретные “флаги” с серверов противника, одновременно защищая свои.
Игра валидаторов унаследовала этот принцип. Валидаторы соревнуются между собой, чтобы определить, кто сумеет предоставить сети более качественный сервис, чьи ноды более стабильны, кто более устойчив к атакам, кто быстрее реагирует на необходимость обновления кода и т.п.
Этот подход не имеет аналогов в централизованном мире. (Представьте себе группу независимых банков, которые перед запуском платежной системы соревнуются между собой, определяя, кто сумеет провести больше платежей клиентам и не сломаться в случае атаки.)
Блокчейны могут использовать свои токены в качестве награды для валидаторов-победителей. Заработанные в соревновании токены могут быть перенесены в основную сеть, либо команда проекта может пообещать победителям место среди валидаторов основной сети.
Критерии победы
Определить критерии игры сложно, поскольку часть из них невозможно подтвердить в децентрализованном окружении. Валидаторы и команда проекта не знают друг друга, и определить наибольший uptime (% времени, когда сервис был доступен) можно только централизованно. Сервис, измеряющий данные параметры, может быть атакован или ему попросту могут не доверять, а в случае расхождения результатов что-то доказать крайне сложно. Если вы хотите использовать традиционные параметры для оценки качества IT-сервисов, необходимо сразу выбрать судью и смириться с тем, что игроки будут собираться централизованно.
Второй путь — отказаться от любых централизованных метрик и использовать только то, что можно проверить в блокчейне. У этого подхода есть огромное преимущество — результаты игры валидаторов может проверить кто угодно, а оспорить эти результаты — очень сложно.
Одной из самых надежных метрик в этом случае является количество блоков, которые произвел каждый валидатор. Косвенно в этой метрике отражено и uptime валидатора (не могли производить блоки в offline), и количество транзакций (кто произвел больше блоков, обработал больше транзакций), и даже награды (за наибольшее количество произведенных блоков). Число валидированных блоков почти для любых PoS- или PoA-блокчейнов является отличной метрикой, за которую могут соревноваться валидаторы. В случае атак, проблем с кодом, нагрузки сети транзакциями самые оперативные валидаторы смогут произвести и обработать большее количество блоков.
Для игры валидаторов можно использовать и экономические параметры. Например, при изначально равных балансах победителей можно определить по количеству токенов, заработанных за время игры. Если в блокчейне валидаторы зарабатывают на комиссиях с транзакций или существуют дополнительные механизмы получения прибыли (например, реферальная система), их могут использовать для “накрутки” токенов. С другой стороны, валидаторы, которые отправляют транзакции самим себе и на этом зарабатывают, автоматически нагружают всю сеть и заставляют других валидировать свои транзакции. Валидаторы могут самостоятельно “атаковать” сеть, т.е. тестировать в экстремальном режиме, что крайне полезно.
Не стоит забывать, что в алгоритмах консенсуса часть блоков (или все) валидируются и подписываются сразу группой валидаторов. Кроме того, на кону могут стоять серьезные деньги. Например, валидатор может исправить код так, чтобы нода пропускала часть проверок и безоговорочно принимала транзакции. Таким образом, он получит преимущество в скорости перед другими валидаторами и освободит ресурсы. Если в сети только “хорошие” транзакции, такое мошенничество могут не заметить. Поэтому во время игры имеет смысл нагружать сеть также и невалидными транзакциями, чтобы цепочки с блоками, пропущенные нечестными валидаторами, откатывались.
Кто игроки?
Сначала кажется, что чем больше людей смогут участвовать в игре, тем лучше. Вы можете потратить серьезные усилия на привлечение максимального количества участников. Однако этот подход может сработать иначе.
Для PoW-сетей важно иметь максимальное число майнеров любого качества, так как они лишь помогают пулам подбирать хеши блоков. В Proof-of-Stake и Proof-of-Authority отвечают за безопасность данных в блоках, их ответственность гораздо выше, а отключение — проблема.
Если в чатах вашего проекта есть сотни желающих запустить свою ноду, то придется организовать массовую поддержку, тратить время на вопросы от новичков, а самое главное — голосовать за них в сети и раздавать им токены на балансы. При этом эффективно работать смогут лишь несколько десятков валидаторов, а остальные будут приходить и уходить, потеряв надежду попасть в топ списка.
Внимательно подходите к выбору валидаторов, старайтесь привлечь хорошие команды и делайте ставку на качество, а не на количество. Вы также можете заранее подготовить документацию, инструкции, средства мониторинга и автоматизировать операции по стейкингу и голосованиям, чтобы команда могла во время игры валидаторов заниматься транзакциями и кодом, а не тратить время на поддержку.
Конечно, не бывает правил без исключений. Мы сталкивались с ситуациями, когда пара хорошо подготовленных ребят на равных соревновалась с именитыми валидаторами, помогала другим участникам и в итоге получила место в мейннете.
Как проводить?
В игре валидаторов основной дирижер — это команда проекта, поэтому не стоит надеяться на комьюнити, а посвятить почти все время поддержке участников. Обязательно возникнут вопросы, баги, новые требования — и потребуется оперативная реакция.
Для сценария игры нужно определиться с функционалом и заранее описать его валидаторам. При этом, как я упомянул выше, не забывайте о проблеме “ленивого валидатора”. Даже если ваши сценарии звучат заманчиво, это еще не значит, что валидаторы будут активно действовать. Зачастую, им ближе парадигма “работает — не трогай”. Они не будут активно атаковать других валидаторов, оптимизировать ноды и пристально следить за игрой, а просто постараются поддерживать сервера.
Помните, что для валидаторов “игра” — это тысячи долларов, сотни часов опытных девопсов, мощные сервера, исследование нового ПО и поддержка 24/7. Без серьезной награды ни одна компания не выделит серьезные ресурсы, поэтому следует трезво оценивать мотивы валидаторов.
Ниже несколько возможных этапов игры:
1. Нагрузка сети случайными транзакциями
Валидаторы должны быть постоянно загружены обработкой разнообразных транзакций. Для этого команда проекта, которая контролирует токен, создает множество аккаунтов и равномерно распределяет нагрузку между соревнующимся.
Есть и более гибкая стратегия, работающая в DPoS-сетях. В сети размещается контракт-giver (его еще называют faucet), который отдает любому из валидаторов фиксированное число токенов в единицу времени. Валидатор может на постоянной основе обращаться к этому контракту (создавая транзакцию) и использовать полученные токены для продвижения в топе валидаторов. В противном случае через некоторое время его вытеснят более активные участники. Этот подход стимулирует валидаторов постоянно формировать новые транзакции, одновременно нагружая и тестируя сеть.
2. Нагрузка сети невалидными транзакциями
Как я описал выше, нечестные валидаторы могут отключить проверку цифровой подписи транзакций и сэкономить ресурсы CPU, чтобы лучше противостоять большому потоку транзакций. Имеет смысл отправлять в сеть невалидные транзакции — тогда блоки, подписанные нечестными валидаторами, будут отсеиваться честными. Пытаться поймать обманщиков таким путем стоит, только если на кону действительно большие деньги или влияние.
3. Проведение DoS-атак на валидаторов
В данном случае игра будет наиболее полной, а валидаторы столкнутся с самыми серьезными проблемами — им придется уводить свои машины из под атаки, менять IP-адреса, оперативно отсекать трафик атакующих и т.п. Как и в случае с нагрузкой транзакциями, лучше всего, если валидаторы сами будут атаковать друг друга с целью получить преимущество в количестве произведенных блоков. Но для этого девопсам придется на время стать злоумышленниками и использовать ПО для проведения атак. Кроме того, более богатые участники могут использовать купленные облачные мощности и повлиять на ход игры.
Для данного этапа хорошей стратегией будет равномерная атака валидаторов командой проекта. Помните, что подобные действия может обнаружить провайдер, и вам может потребоваться документальное подтверждение факта проведения атаки с целью тестирования.
4. Обновление кода
Обновление кода ноды — штатная задача, которую должен уметь выполнять любой валидатор, поскольку с ним придется столкнуться в основной сети. Эти процедуры могут быть как очень простыми, так и довольно сложными (например, если требуется replay цепочки с нуля).
Лучший вариант — если баг не позволяет производить новые блоки, а исправление — восстанавливает этот функционал. В этом случае те валидаторы, которые быстрее смогли обновиться (а, возможно, и перестроить цепочку с genesis блока) смогут быстрее вернуться к производству блоков и получат преимущество в игре.
5. Другие сценарии
Существует множество сценариев, которые можно включить в игру. Команда проекта может добавить бонусы за действия, полезные для сети: публикацию кода для мониторинга и управления нодами, активность в governance-протоколах и т.д. Все ограничено только вашей фантазией.
Однако помните о “ленивых валидаторах”. Если награждаемые действия требуют сложных взаимодействий или разработки специализированных инструментов, валидаторы вряд ли пойдут на это.
Заключение
Игра валидаторов — это прекрасный способ собрать команду профессионалов, способных обеспечить блокчейну надежную защиту, наградить наиболее подготовленные к трудностям команды и провести яркое маркетинговое мероприятие, которое не имеет аналогов в скучном централизованном мире.
Поднимаем основную сеть
Мы добрались до запуска основной сети (мейннета) проекта. Разработка, тестирование, запуск тестовой сети и выбор валидаторов уже позади. Впереди — раздача реальных балансов токенов участникам и ответственность за безопасность значительных сумм.
В данной статье руководитель отдела исследований MixBytes Сергей Прилуцкий расскажет о нюансах запуска основной сети.
Наиболее важные шаги для технической команды — запуск тестнета и игры валидаторов — завершены, и к этому моменту сеть должна быть технически готова. К сожалению, «децентрализованная сеть» вовсе не означает, что все запустится автоматически. Запуском основной сети придется активно заниматься команде, которая отвечает за код блокчейна.
Genesis и начальное состояние
Genesis-блок — первый блок основной сети. Проще говоря, он содержит всю начальную информацию: стартовые балансы, код основных смарт-контрактов, список первоначальных валидаторов.
На деле блоки не содержат данные, а только хеши состояний. Для большинства блокчейнов стартовое состояние — это сразу несколько файлов, часть из которых является снапшотом базы данных. Именно с него начнется жизнь базы данных состояния блокчейна на всех нодах сети. Любая нода основной сети обязана стартовать цепочку именно с этих данных, иначе весь блокчейн будет невалидным.
На старте у команды есть список адресов или публичных ключей тех, кто получит на баланс токены, и код основных контрактов. Список может меняться вплоть до последних часов перед запуском, поэтому имеет смысл сделать скрипт, который из списка адресов-балансов создает начальное состояние (genesis-блок и все необходимое). Скрипт может выводить на экран все адреса и информацию о начальном состоянии, а его запуск можно транслировать в онлайн-режиме на Youtube.
Так вы сможете задокументировать запуск, а повторить эту операцию сможет любой пользователь, который сомневается в честности распределения стартовых балансов или содержимом контрактов.
Старт производства блоков
Для старта производства блоков требуется участие нескольких валидаторов. Некоторые из них могут столкнуться с проблемами: часть команд может перепутать конфигурации тестовой и основной сетей, другая — использовать устаревшее начальное состояние, третья — неправильно оценить ресурсы серверов и т.д. Поэтому не стоит пугаться, если новые блоки вы увидите не сразу.
Наберитесь терпения или проектируйте запуск так, чтобы подключение новых валидаторов было постепенным. Например, запустите сеть на своих машинах, постепенно уступая места новым валидаторам, или подключите небольшое число валидаторов на старте сети и увеличивайте его по мере добавления новых.
Советую заранее подготовить скрипты, которые выводят список работающих валидаторов, а также чек-лист для их самопроверки.
Аккаунты валидаторов
Каждый валидатор сети имеет аккаунт, который используется для подписи блоков, голосований за других валидаторов и других важных функций. Для работы валидатора приватные ключи располагаются на сервере валидатора.
Этот сервер может быть атакован несколькими способами — от атаки на ПО валидатора до атаки на аккаунты девопсов, поэтому нужно использовать ключи, получение которых не позволит атакующему контролировать средства валидатора. Например, в DPoS консенсусах на адресе валидатора нет криптовалюты, но за него «голосует» другой адрес с отдельной машины. В случае взлома валидатора, можно запустить другого и переголосовать за него. Отличной практикой является передача вознаграждений за валидаторство на независимый внешний адрес.
Отдельно нужно отметить роль мультисиг-адресов (см. статью). Они являются обязательными, поскольку взлом любого из мультисиг-адресов не будет фатальным. Для полного доступа к средствам нужно получить доступ к нескольким (минимум двум) приватным ключам вместо одного (количество необходимых подтверждений может меняться).
Примером мультисиг-активности может быть участие в «выборах» валидаторов, для которых требуется стейкинг средств на смарт-контракте, выбирающем валидаторов. Сервер валидатора раз в сутки отправляет транзакцию-заявку, но она не является действительной, пока с другого адреса не будет отправлена транзакция-подтверждение. Подтверждение отправляется с любой независимой от валидатора машины, взлом которой также не даст полного доступа к средствам валидатора.
Несмотря на мощную защиту, многие валидаторы не любят мультисиг-логику, так как это дополнительные сервисы, за которыми нужно следить. Для подобной деятельности обычно используются скрипты, которые автоматически мониторят нужные валидатору адреса и подтверждают необходимые транзакции.
Подобное ПО обязательно должно проверять как минимум адрес, которому адресована подтверждаемая транзакция или тип вызываемой функции смарт-контракта. Без подобной проверки злоумышленник может создать транзакцию, выводящую средства с адреса валидатора, а скрипт автоматически подтвердит и подпишет ее дополнительным ключом — в этом случае защита с помощью мультиподписи теряет смысл.
Режим бога
Не всегда при запуске блокчейна можно быть уверенным, что все пойдет как надо. Возможно, вы захотите изменить системные смарт-контракты в первые месяцы существования сети или вам придется дорабатывать сеть на ходу из-за требований со стороны бизнеса.
Вам также может потребоваться оперативно вносить изменения в системные контракты без сложных процедур согласования. В этом случае допускается создание специальных «всемогущих» аккаунтов, которым разрешено менять код системных контрактов и иметь доступ к аккаунтам участников. В этом случае имеет смысл заложить и публично продемонстрировать логику, которая отключит этот функционал после определенного времени и повысит уровень доверия к сети.
Не рекомендуется оставлять такие аккаунты надолго, особенно после появления токена сети на биржах или его доступности для обмена — в этот момент возможна организация атак, способных полностью подорвать капитализацию сети.
«Всемогущий» аккаунт — заманчивая цель для атаки, способной нанести серьезный ущерб сети даже в корпоративных блокчейнах .
Мосты
Часто токены проекта сначала выпускаются в сети Ethereum, а для создания своего токена требуется лишь несколько несложных действий в браузере. Только после запуска основной сети держатели токенов могут перенести свои балансы в запущенную сеть. ПО, используемое для переноса токенов из одного блокчейна в другой, получило название «мосты».
Мост между двумя блокчейнами — это сервис, который мониторит одновременно обе сети. Когда пользователь хочет переместить токены, мост «забирает» их в исходной сети и «выдает» в требуемой.
Мосты могут быть однонаправленные (перемещают токены только из одной сети в другую), либо двунаправленные (перемещают токены в обоих направлениях). Механика работы мостов может быть очень разной в зависимости от того, какие виды смарт-контрактов поддерживают обе сети.
В большинстве случаев операторами мостов являются валидаторы сети. Они принимают токены вашего проекта в Ethereum на специальный смарт-контракт, и, убедившись в их получении, выдают соответствующую сумму токенов в вашем блокчейне и в обратном направлении.
Для сетей на базе Ethereum, EOS или других с полноценными многофункциональными смарт-контрактами существуют универсальные имплементации мостов (пример) или проверенные алгоритмы действий.
Мост с биткоинподобными сетями — это гораздо более сложная задача из-за UTXO-дизайна адресов.
Мосты должны быть спроектированы заранее и протестированы на этапе тестнета.
Мониторинг
В децентрализованной сети валидаторы отвечают за мониторинг и следят за работоспособностью своих серверов. Команда проекта, в свою очередь, тратит ресурсы на поддержку только своих валидаторов. Нужно ли собирать мониторинговую информацию со всех валидаторов сети и самим платить за поддержку серверов мониторинга?
Решать вам — для мониторинга в основной сети вам понадобится лишь пара дополнительных серверов для централизованного сбора метрик с валидаторов, а польза от этого сервиса довольно велика — все участники смогут получать общую, агрегированную информацию о работе сети.
При запуске вашей команде будет поступать большое число вопросов: какие валидаторы активны, корректно ли они работают, какова их производительность по сравнению с коллегами? Стоимость этих не очень требовательных серверов, возможно, окупит рабочее время ваших специалистов.
Не обязательно постоянно поддерживать этот сервис — вы в любой момент можете выключить его, а валидаторам будет достаточно запустить собственную копию и изменить пару адресов, чтобы запустить собственный мониторинг.
Дополнительное ПО
Обозреватель блоков
Без сомнения, это важнейший сервис блокчейна, отображающий информацию о блоках и транзакциях. Однако на этапе запуска транзакций и адресов крайне мало, и по сравнению с тестнетом или с игрой валидаторов обозреватель блоков не сильно интересен участникам на начальных этапах. Большинство активно работающих аккаунтов — это валидаторы и разработчики, которые предпочтут использовать различные специализированные утилиты для получения нужной информации.
Создание качественного и удобного обозревателя блоков основывается в первую очередь на опыте пользователей — а его пока крайне мало. Работать этот сервис должен, но на старте сети не требует чрезмерного внимания.
Портал валидаторов
В первые недели жизни сети портал для валидаторов крайне важен, так что я рекомендую потратить на него время и добавить хотя бы простейшую агрегацию данных. Например, uptime валидаторов, количество произведенных блоков, статистика по стейкингу, голосованиям и наградам валидаторов.
Предоставив участникам возможность проверять и контролировать себя, вы быстрее увидите потенциальные проблемы и сможете точнее отвечать на любые вопросы, касающиеся экономики сети.
Утилиты командной строки
Если нужно, чтобы валидаторы с первых запусков могли автоматизировать основные задачи, определять проблемы и реагировать на них — обязательно нужны утилиты, которые позволяют проводить голосования, узнавать статус валидатора, подтверждать multisig-транзакции и т.п.
Кажется, что обеспечить качество этого вида ПО намного проще, чем сделать хороший обозреватель блоков или кошелек. Однако на практике частые изменения в коде будут ломать схемы автоматизации на стороне валидаторов, что может привести сеть к неприятным сбоям и конфликтам.
Внимательно отнеситесь к этим инструментам, старайтесь не переименовывать параметры и их формат «для красоты» после запуска и жестко следуйте стандартам, принятым в разработке свободного ПО. По качеству именно этого ПО валидаторы будут судить о степени подготовки вашей команды.
Кошелек и основные приложения
Ради работы этого ПО и затевался блокчейн. К моменту запуска мейннета каждый пользователь на вес золота, поэтому любое исправление в коде кошелька или основного децентрализованного приложения сети должно быть быстрым. Для этого нужно отладить весь цикл выкатки кода еще в тестнете, добавить подробный мониторинг и бороться за каждого пользователя.
http://forklog.com/ (C)
Не является индивидуальной инвестиционной рекомендацией
При копировании ссылка обязательна Нашли ошибку: выделить и нажать Ctrl+Enter
Перед разработкой собственного блокчейна ваша команда должна четко понимать, для чего необходим блокчейн и какой бюджет вы сможете выделить на его содержание.
Проектирование и запуск блокчейна имеют свои нюансы. Их можно легко упустить при планировании, если вы неверно оценили объем и сложность задачи.
Чтобы помочь проектам избежать таких ошибок, руководитель отдела исследований MixBytes Сергей Прилуцкий подготовил пошаговое руководство по запуску блокчейна.
Определение круга технических задач
Задача блокчейна — принимать от пользователей транзакции и точным и неоспоримым способом обрабатывать каждую из них. Результаты работы каждой транзакции записываются в общедоступную базу данных (state database) на каждой машине блокчейн-сети. Любой участник может воспроизвести и перепроверить эту базу данных, если у него есть данные о ее первоначальном состоянии и журнал всех транзакций или блоков.
Чтобы правильно выбрать блокчейн, техническим специалистам прежде всего нужно определить типы транзакций и как будет работать каждая из них. Для классификации удобно использовать традиционные серверные ресурсы: процессор, оперативная память, сетевой трафик, хранилище (cpu, mem, network, storage).
Некоторые транзакции требуют мало времени процессора (ничего не вычисляют), зато они могут изменить сразу несколько балансов и записать большой объем данных в хранилище (storage). Другие транзакции сильно нагружают процессор, чтобы произвести криптографические вычисления, но результатом будет единственное небольшое значение, записанное в хранилище. В первом случае больше работы достанется жесткому диску и оперативной памяти, а во втором — процессору. Эти параметры могут сильно повлиять на стоимость серверов вашего блокчейна, поэтому оценка характера транзакций — важная часть технического дизайна.
Помимо транзакций большое значение имеют сценарии работы блокчейна: какое количество каких транзакций от какого количества аккаунтов сеть обрабатывает в единицу времени. Это может быть всего десяток аккаунтов, каждый из которых отправляет много транзакций в сеть, или постоянный приток тысяч новых аккаунтов, которые заключают одну небольшую сделку. Нужно понимать, что сети для игр, финтех-приложений или криптографических протоколов сильно отличаются по характеру нагрузки на ноды.
Любая логика, сложнее чем просто перевод токенов с адреса на адрес, требует использования определенного кода (смарт-контракты, runtime и т.п.). Работая над проектом блокчейна необходимо учесть, какая виртуальная машина для исполнения такого кода будет использоваться в проекте:
Вариант 1: специализированная виртуальная машина (VM)
Примеры: EVM (Ethereum), TVM (TON)
Специализированные VM, как правило, ограничены и заточены строго под смарт-контракты своей платформы. Они порождают более предсказуемые результаты, являются наиболее безопасными и точно учитывают ресурсы, потраченные на обработку транзакций.
Вариант 2: стандартная виртуальная машина
Примеры: Web Assembly в EOS, Parity Substrate (Polkadot).
WebAssembly (WASM) — это веб-стандарт, используемый для создания кода, исполняемого на стороне клиента и более производительного, чем jаvascript. Теоретически, смарт-контракты под WASM можно писать на любом языке, но для блокчейнов лучше подходят низкоуровневые языки (C, C++, Rust и т.д.), иначе получившийся код будет плохо оптимизирован.
WASM также ведет учет потраченных на исполнение ресурсов. Имея большую функциональность контрактов, WebAssembly менее безопасна, чем специализированная виртуальная машина.
Вариант 3: обработка транзакций нативным кодом
Примеры: Hyperledger Fabric, Cosmos.
Обработка нативным кодом используется, когда код, обрабатывающий транзакцию, фактически встроен в ноду. Минус данного варианта — наименьшая безопасность и детерминированность обработки транзакций; плюс — высокая функциональность (разработчикам доступны любые функции языка без ограничений).
Еще одним из критериев выбора блокчейна является способ обновления кода контрактов. При эксплуатации системы неизбежно будут возникать ошибки и необходимость добавлять и изменять функциональность системы. В современных блокчейнах эти задачи можно решать несколькими способами.
Вариант 1: пользовательские смарт-контракты
Примеры: смарт-контракты в Ethereum, EOS, TON, Parity Substrate (с модулем пользовательских смарт-контрактов WASM или EVM).
В этой схеме любой пользователь может создать смарт-контракт или несколько, соединенных в сложную систему. Контракты можно размещать и обновлять без взаимодействия с валидаторами сети.
Эта схема — наиболее гибкая. Она позволяет строить системы контрактов произвольной сложности, но требует более сложной логики работы ноды, потому что код контрактов является недоверенным и может содержать все что угодно. Поэтому нужно, чтобы нода исполняла такой код крайне осторожно, ограничивая его по времени и запрашиваемым данным, и не позволяла бы влиять на консенсус.
Вариант 2: код runtime, контролируемый валидаторами
Примеры: runtime в Parity Substrate, Application в Cosmos.
Данную схему можно представить в виде одного большого смарт-контракта, который обрабатывает все виды транзакций. Код проверяют валидаторы и голосуют за применение изменений, после чего новая логика начинает работать. При этом разработчики избавлены от большого числа ограничений и могут создавать код runtime из набора готовых модулей.
Эта схема делает более сложным изменение кода, который обрабатывает транзакции, но позволяет не делать дополнительные проверки безопасности. Валидаторы в данной схеме обязаны проверять изменения и не пропускать уязвимый код, иначе рискуют получить неработоспособный блокчейн.
Зато разработчики такого «runtime» получают в распоряжение гораздо больше возможностей и ресурсов, чем в схеме с пользовательскими контрактами. Эта схема особенно актуальна для парачейнов (небольших дочерних цепочек с отдельным функционалом, являющимися частями большой системы из множества блокчейнов).
Без понимания характера транзакций, особенностей виртуальной машины и логики работы смарт-контрактов проект может крайне неоптимально использовать блокчейн. Например, поддерживать работу дорогостоящего ПО ради простейших операций или проводить рискованные обновления основного кода ноды ради небольших исправлений в логике.
Ограничения блокчейна
При запуске собственного блокчейна нужно оценить технические требования клиента и понять, насколько они выполнимы.
Одним из таких требований является время «исполнения» транзакции на стороне клиента. Частой ошибкой является оценка скорости только на основе tps (количество транзакций в секунду).
Разработчики, как правило, оценивают tps как количество транзакций в блоке ко времени блока. Например, под «1000 tps» имеется в виду, что время между блоками равно 1 секунде, а в блоке может быть до 1000 транзакций. Это не значит, что блокчейн обрабатывает одну транзакцию за 0.001 секунды, поскольку время обработки транзакции зависит от времени производства блока.
Если время производства блока — 3 секунды, то время обработки одной транзакции может достигать 3-х секунд (от момента отправки транзакции и до появления следующего блока). 3000 tps (при максимуме в 1000 транзакций в блоке) можно достичь только при параллельной отправке транзакций с разных аккаунтов.
Еще одно важное ограничение современных блокчейнов — это число валидаторов (серверов, производящих и подтверждающих блоки). Произведя блок, валидаторы обязательно приходят к согласию (консенсусу) относительно него. Время производства блока зависит от числа валидаторов и числа сообщений, которыми им надо обменяться. Для любого сетевого консенсуса требуется согласие минимум 1/2 N + 1 валидаторов, а с полными гарантиями безопасности — согласие 2/3 N + 1 валидаторов. Данные значения являются фундаментальными, обойти их нельзя, так как они обеспечивают устойчивость сети к злонамеренному поведению участников.
Если вы планируете запускать блокчейн, забудьте о мгновенных ответах клиентам и миллионах валидаторов. Такие масштабы достижимы только с появлением полноценных квантовых технологий связи и криптографических вычислений.
Планирование запуска и поддержки сети
Предположим, вы выбрали блокчейн и собираетесь его запускать. Каковы дальнейшие шаги?
Шаг 1: выбор имплементации, оценка трудозатрат
Прежде всего, необходимо выбрать конкретную технологию, оценить риски и трудозатраты на реализацию проекта, а также учесть ограничения конкретных решений. Решение может быть уже проверенным в реальных условиях или находиться на стадии разработки.
В случае, если вы запускаете собственноручно разработанное решение, изучите наиболее близкие аналоги. Так вы сможете сэкономить время и учесть проблемы, которые до вас уже решили другие команды.
Шаг 2: Тестовые запуски и масштабное тестирование сети
Тестирование сети — это проверка работоспособности блокчейна с числом валидаторов, приближенным к реальности. Если блокчейн подразумевает 100 валидаторов, необходимо убедиться, что сеть работоспособна под нагрузкой.
При тестировании будет подготовлена инфраструктура для автоматического разворачивания сети с несколькими валидаторами, что пригодится на последующих этапах.
Без тестирования есть серьезный риск, что сетевой консенсус содержит ошибки или уязвимости, особенно если это собственное решение, а не хорошо известный алгоритм. Собирать информацию о проблемах в уже запущенной сети будет очень непросто.
Шаг 3: Запуск тестовой сети (testnet)
Testnet нужен, чтобы пользователи и команда могли опробовать в ней то, что будет работать в основной сети (mainnet). Весь функционал основной сети должен присутствовать в тестовой, а клиентские приложения — поддерживать обе сети. Благодаря точности смарт-контрактов, тестирование рабочих продуктов можно провести с 99% точностью, с реальными балансами реальных пользователей.
В testnet можно раздать токены, проверить, как валидаторы запускают свои ноды, провести первые сделки вместе с активными пользователями, а полученные результаты позже использовать в mainnet.
Некоторое ПО необходимо будет поддерживать сразу после запуска тестовой сети (например, веб-интерфейс для валидаторов, мониторинг или обозреватель блоков). Информация, полученная на этапе запуска этих сервисов в тестовой сети, пригодится при «чистовом» запуске в mainnet.
Именно на этом этапе будет видно качество работы команды проекта — насколько стабильно запущенное ПО, насколько качественно была написана документация, насколько быстро потенциальные валидаторы смогли поднять требуемый софт, сколько раз пришлось вносить исправления и т.д.
Шаг 4: определение процедуры добавления валидаторов mainnet
Обычно в роли валидаторов сети выступают независимые компании, поэтому собрать их вместе и заставить синхронно выполнить какие-то действия почти невозможно. Все процедуры должны предусматривать произвольный порядок действий валидаторов, учитывать их географическое распределение и степень неподготовленности.
Наиболее популярный вариант выбора валидаторов на сегодняшний день — процедуры, предусмотренные алгоритмами DPoS. В этом случае владельцы токенов голосуют своими балансами за валидаторов. Топ валидаторов, набравших большинство голосов-токенов получают право производить блоки. В proof-of-authority (POA) сетях и коропоративных блокчейнах, ситуация аналогична, но вместо балансов токенов используются голоса других валидаторов.
Перед стартом основной сети нужно сформировать начальный список валидаторов и решить, в какой момент начнется полноценное производство блоков. Технически команда может сразу прописать всех валидаторов в начальных блоках сети или запустить сначала только своих валидаторов, а потом постепенно заменять их на новых.
Шаг 5: запуск основной сети
Запуск mainnet должен сопровождаться активным мониторингом. Желательно, чтобы сводная информация от всех валидаторов была представлена в одном сервисе — так команда проекта сможет более активно реагировать на проблемы в сети.
Новые требования также предъявляются к работе обозревателя блоков — главного внешнего сервиса сети. Он должен автоматически переключаться на запасные сервера в случае сбоев, так как информация о транзакциях крайне важна пользователям и команде проекта. Также может потребоваться резервное копирование, если обозреватель хранит предоставленную пользователями информацию (например, верификация кода контрактов в Etherscan).
Довольно капризным в плане поддержки на этом этапе может являться мост — ПО, которое позволяет переносить токены из одного блокчейна в другой. От его работы зависят балансы реальных пользователей, поэтому необходимо уделить особое внимание его безопасности.
Шаг 6: Поддержка и обновление кода
После запуска основной сети работа команды не прекращается, особенно если блокчейн построен на основе существующих решений. Базовый код тоже развивается, и в нем накапливаются важные исправления ошибок и оптимизации. Эти изменения необходимо переносить в проект и своевременно обновлять код блокчейн-нод.
На этом этапе очень важна разработанная документация и процедуры, которые должны были быть опробованы в тестовой сети. При обновлении кода не должно происходить накладок, потому что в этом случае валидаторы теряют деньги, время и репутацию. В mainnet может существенно меняться состав валидаторов, и в случае их недостаточной поддержки или некачественной документации это может привести к проблемам в работе сети.
Заключение
При правильном подходе запуск блокчейна на базе уже работающих решений не несет серьезных рисков. Как правило, проблемы носят экономический или организационный характер, не связанный с внутренним кодом нод.
Построенные на основе публичных сетей (Ethereum, EOS) решения являются достаточно надежным ПО, доступным пользователям интернета без ограничений. Этим свойством не могут похвастаться централизованные финансовые системы: выставить в открытый доступ банковское API или базу данных с критичной информацией без регистрации, логинов/паролей и мониторинга не представляется возможным.
Хотя разработка и запуск блокчейна довольно затратны, реальная эксплуатация может приятно удивить участников безопасностью, саморегуляцией и способностью сети сохранять работоспособность и точность исполнения транзакций в сложных условиях.
Выбираем алгоритм консенсуса
Перед разработкой собственного блокчейна ваша команда должна четко понимать, для чего необходим блокчейн и какой бюджет вы сможете выделить на его содержание.
Проектирование и запуск блокчейна имеют свои нюансы. Их можно легко упустить при планировании, если вы неверно оценили объем и сложность задачи.
Чтобы помочь проектам избежать таких ошибок, руководитель отдела исследований MixBytes Сергей Прилуцкий подготовил пошаговое руководство по запуску блокчейна.
Данная статья поможет вам определиться с выбором алгоритма консенсуса для построения собственного блокчейна, исходя из его технических свойств и ограничений (они подробно описаны в предыдущей статье).
***
Я буду исходить из того, что блокчейн предназначен для достаточно сложных сделок. Все рассматриваемые решения подходят для работы с кодом, размещенным в блокчейне.
Я намеренно не включил в перечень решения, которые находятся на ранних этапах развития, неизвестны широкому кругу программистов или не имеют важных механизмов, обеспечивающих безопасную работу блокчейна: неустойчивы к византийскому поведению нод (non-BFT) или могут быть успешно атакованы с единственного аккаунта. Без этих свойств блокчейн не имеет ценности и превращается в медленную, дорогую и неудобную в использовании базу данных.
Чтобы определиться, строить ли новую систему или использовать готовое решение, в первую очередь необходимо определиться с консенсусом — главным алгоритмом, обеспечивающим блокчейну BFT-свойства.
Консесусы: proof-of-work, proof-of-stake, proof-of-authority
Для начала рассмотрим разные типы консенсуса с точки зрения запуска и эксплуатации сети. Любой BFT-консенсус в блокчейнах должен удовлетворять как минимум два важных свойства распределенных систем: safety и liveness.
Safety гарантирует, что алгоритм никогда не придет к неверному консенсусу, если большинство узлов честно следуют протоколу, а liveness — что алгоритм никогда не «застрянет», не имея возможности выбора пути.
Эти свойства должны гарантированно выполняться при наличии в сети byzantine-участников, намеренно действующих наихудшим образом.
Proof-of-work (PoW)
Преимущество этого типа консенсуса — отсутствие необходимости регистрировать в сети валидаторов. Принимается любой блок, удовлетворяющий требования, без подтверждения других участников. Это позволяет оставить лишь часть логики, отвечающую за изменение сложности майнинга.
В теории этот вид консенсуса допускает любое число валидаторов — ведь соревноваться за блок может сколько угодно валидаторов. В реальных сетях, если валидаторов (майнеров) много, а сложность сети высока, то шансов получить награду за блок у отдельного майнера крайне мало. Для такого консенсуса необходимо сразу планировать работу майнинговых пулов, объединяющих майнинговые мощности, и соответствующее ПО.
При старте сети валидаторы должны сразу же установить серьезные вычислительные мощности. Это часто упускают из вида, надеясь на постепенное увеличение сложности сети и количества майнеров. Невысокий хешрейт открывает двери для недорогих атак 51%, когда атакующий на очень короткое время арендует много серверов, чтобы получить 51% хешрейта сети, и проводит атаку двойной траты.
Поэтому для PoW-сети придется планировать более сложную процедуру запуска. Сначала команда запускает сеть с собственными валидаторами, а потом постепенно «уступает» производство блоков майнерам, которые в этом случае могут плавно наращивать мощности.
Proof-of-authority (PoA)
PoA-консенсусы — это алгоритмы, использующие заранее назначенный набор аккаунтов, которые могут производить блоки и голосовать за принятие и исключение новых членов. Этот вид консенсуса — естественный выбор для корпоративных блокчейнов и тестовых сетей. Здесь может вообще не быть внутреннего токена, а при голосованиях за блоки и при выборах валидаторов 1 валидатор = 1 голос.
Это семейство алгоритмов представлено фундаментальным алгоритмом pBFT. В измененном виде он является базой для большого числа консенсусов, позволяя договориться о любых данных со всеми гарантиями безопасности.
В предыдущей статье я уже говорил о том, что не существует гарантированно безопасных консенсусов, в которых требуется менее, чем 2/3 + 1 сообщений от валидаторов. pBFT это доказывает математически. В разных консенсусах эти сообщения, подтверждающие, что валидатор принимает блок, собираются в разные моменты времени.
Процесс сбора подтверждений и в дальнейшем признание блока окончательным получил отдельное название финализации. Блоки, на которых достигнут общий консенсус называются финальными. Для уменьшения числа сообщений в части алгоритмов финальность достигается не на всех блоках, а только на некоторых, «заверяющих» сразу несколько блоков. Таким образом сильно уменьшается число сообщений между валидаторами и существенно ускоряется консенсус.
Из-за разделения процедур валидации блоков и финализации присутствует некоторая путаница, из-за которой оценивать скорость консенсуса становится непросто.
Например, алгоритм pBFT, используемый в консенсусе Tendermint (Cosmos), требует консенсуса на каждый блок, т.е. мгновенно финализирует его, а алгоритм EOS финализирует лишь один из множества блоков, финализируя сразу цепочку.
Aura — популярный алгоритм для POA-сетей на базе Ethereum — использует псевдослучайный выбор валидатора для каждого блока и параллельно договаривается о финализированных блоках с использованием алгоритма GRANDPA, ожидая > 2/3 подписей-подтверждений от других валидаторов. Такой параллельно работающий алгоритм финализации получил название finality gadget.
Похожим образом работает консенсус EOS, создающий «расписание» для валидаторов на некоторый период времени (epoch) и требуя финализации блоков в конце каждой epoch.
Proof-of-stake (PoS)
Почти все существующие реализации этих алгоритмов включают в себя алгоритмы из POA-консенсусов, что добавляет путаницы. Современные PoS-алгоритмы работают следующим образом: при помощи балансов участвующих в выборах валидаторов (стейков) формируется список валидаторов (например, голосованиями, заморозкой депозитов и т.д.). В течение некоторого времени, до момента изменения списка валидаторов, сеть работает, используя PoA-алгоритм, например pBFT.
Наиболее распространенными стали алгоритмы, названные Delegated Proof-of-Stake (DPoS), где аккаунты в сети различными способами голосуют своими балансами за валидаторов, формируя топ из N валидаторов.
Выбирая консенсус для своего блокчейна, стоит в первую очередь рассмотреть процесс финализации блоков. От нее будет зависеть время, через которое клиент получит подтверждение своих транзакций. Токеномику, процедуру «выборов» валидаторов и получение наград за блоки лучше рассматривать отдельно. В этой части может быть применено большое число разных экономических механизмов.
Отмечу, что корпоративным сетям не стоит пренебрегать экономическими механизмами и PoS-алгоритмами, даже если в сети нет никакой экономики и токена. Любые бесплатные транзакции — это почти всегда вектор атаки на систему с единственного аккаунта. Наличие баланса «технического» токена на аккаунте может служить удобным ограничителем, когда у атакующего просто не хватит средств на полномасштабную атаку, а также позволит более гибко регулировать доступ и нагрузку на сеть.
Варианты имплементации
Планируя свой блокчейн, надо понять, можно ли использовать готовое решение или стоит создать все с нуля, полностью контролируя код.
Блокчейн — это мир открытого ПО. Закрытый код в нем практически невозможен — криптографические протоколы давно создаются на открытых международных конкурсах, а реализациям с закрытым кодом мало кто доверяет из-за больших рисков.
Используйте то, что создали программисты до вас. Крайне велика вероятность, что ваши задачи уже решали, обсуждали и проверяли, поэтому не стоит тратить на них лишние усилия.
Если же вы решили делать свой консенсус, связанный с сетевым взаимодействием, или вы используете новые криптографические концепции, которые архитектурно не укладываются в традиционный дизайн блокчейнов; если вы собираетесь обойти все существующие решения по производительности, экономя каждый бит; если транзакции в вашем блокчейне настолько специфические, что ничего подобного в мире не существует… Тогда ваш путь — блокчейн с нуля.
Выбираем движок
Перед разработкой собственного блокчейна ваша команда должна четко понимать, для чего необходим блокчейн и какой бюджет вы сможете выделить на его содержание.
Проектирование и запуск блокчейна имеют свои нюансы. Их можно легко упустить при планировании, если вы неверно оценили объем и сложность задачи.
Чтобы помочь проектам избежать таких ошибок, руководитель отдела исследований MixBytes Сергей Прилуцкий подготовил пошаговое руководство по запуску блокчейна.
Данная статья поможет вам определиться с выбором движка для построения собственного блокчейна.
Блокчейн с нуля
Попытки создать блокчейн с нуля без сомнения похвальны, ведь благодаря им появились многие существующие решения. Тем не менее нужно трезво оценивать возможности своей команды.
Написание с нуля кода блокчейн-ноды напоминает создание собственной базы данных с механизмом надежной сетевой репликации. Если вы поищете, сколько таких БД было создано за последние десятилетия, то найдете максимум сотню проектов. Огромной долей рынка владеют всего несколько компаний (Oracle, MS SQL Server, MySQL, PostgreSQL), а разработчики ядра таких систем ценятся крайне высоко.
Для разработки блокчейн-ноды вам придется собрать команду очень крутых и редких специалистов, имеющих опыт работы с многопоточным программированием, криптографией, сетевыми протоколами, сложными внутренними алгоритмами и понимающих работу современных операционных систем.
Особенное место для блокчейнов занимает тестирование, так как алгоритмы консенсуса могут прекрасно себя вести на нескольких валидаторах и совершенно по другому при наличии десятков и сотен узлов под нагрузкой. Увеличение числа разработчиков в данном случае приведет разве что к усложнению коммуникаций внутри команды.
По опыту нашей компании, бизнес-заказчики редко выбирают этот путь. Создание своего блокчейна — это задача для группы исследователей, энтузиастов, которые могут себе позволить работать свободно, не имея жестких сроков и бизнес-плана. Такая команда должна иметь возможность свободно исследовать любой встретившийся вопрос, не сильно заботясь о сроках сдачи проектов. На текущий момент работа над такими проектами, как биткоин и Ethereum, производится независимыми разработчиками по всему миру, без жестких дедлайнов. Внешнее давление бизнес-факторов может сыграть с вашим проектом злую шутку, заставив быстрее решать проблемы, не продумав последствия.
Готовые блокчейн-движки
Я намеренно назвал раздел «движки», так как этот термин в области ПО часто используется для обозначения комплексов разнопланового ПО, предназначенного для решения конкретной задачи. Например, «поисковый движок» или «графический движок» — это не только код, но и вспомогательное ПО, дополнительные утилиты, описания алгоритмов и многое другое. Учитывая существование нескольких основных ядер блокчейнов, на базе которых построены уже существующие сети, будет удобно называть их движками (например, «построен на движке Ethereum»).
Если ваш блокчейн не обладает уникальной архитектурой и ваша задача — доставка решения за определенный промежуток времени, лучшим вариантом будет работа с уже существующими движками. Они позволяют реализовать ваш вид консенсуса и транзакций, по-своему организовать управление валидаторами сети. Вы сможете использовать готовый открытый код, проверенный в реальных сетях. Вам не придется изменять код блокчейн-ноды, а для реализации своей логики нужно будет менять только часть, предусмотренную разработчиками движков. Не внося новых уязвимостей и не решая проблемы сетевого слоя, вы сможете сосредоточиться только на бизнес-логике вашего блокчейна.
Разберем готовые для работы блокчейн-движки, используя которые вы сможете запустить собственный блокчейн, спроектировать и реализовать его внутреннюю экономику и организовать запуск для проведения сложных сделок.
Ethereum
Этот комплекс ПО построен на базе ядра публичного блокчейна Ethereum. Публичный Ethereum использует консенсус типа Proof-of-Work, а его многочисленные тестовые сети — различные виды Proof-of-Authority и Proof-of-Stake консенсусов. ПО отвечает самым строгим критериям безопасности, проверено в десятках реально работающих сетей и, на мой взгляд, является наиболее развитым для создания блокчейнов с любыми видами консенсусов и полноценными, многофункциональными смарт-контрактами.
Нужно отметить роль проекта POA Network, чьи разработчики проделали огромную работу и запустили уже несколько быстрых и надежных сетей. POA Network существенно быстрее оригинального Ethereum, но при этом обладает той же стойкостью и универсальностью для заключения любых сделок, а роль валидаторов (майнеров) исполняют компьютеры, честная работа которых заверяется юридически. Эту сеть можно считать эталоном для запуска корпоративных блокчейнов на базе Ethereum.
Код блокчейн-ноды и консенсус
Существуют две основных имплементации кода ноды Ethereum: на языке Rust (код, названия: poa-parity (старое) или openethereum(новое)) и на Go (код, название: geth).
На момент написания при построении PoA-сети на geth (Go) вам будет доступен только консенсус Clique — это простейший и небезопасный протокол без финализации, который можно использовать только в тестовых целях.
Консенсус, реализованный в poa-parity (Rust), состоит из двух алгоритмов: schedule валидаторов Aura и finality gadget GRANDPA. Именно этот вариант, проверенный и безопасный, работает в POA-сетях на базе Ethereum. POA Network работают также над имплементацией перспективного BFT-консенсуса HoneyBadger.
Отдельного упоминания заслуживает новая блокчейн-нода Nethermind, написанная на C# для платформы .NET Core. Она полностью поддерживает Ethereum, большое число операционных систем и является отличным выбором для компаний, которые используют .NET Core.
Смарт-контракты и управление сетью
POA Ethereum использует виртуальную машину EVM и смарт-контракты, которые лучше всего писать на языке Solidity. EVM давно стала стандартом для виртуальных машин с большим количеством готового кода и паттернов разработки. Код контрактов под EVM отвечает за большие суммы криптовалюты, и любая найденная уязвимость вызывает мощную реакцию сообщества и СМИ, поэтому безопасность контрактов EVM на текущий момент крайне высока.
Управление списком валидаторов осуществляется посредством смарт-контрактов — это потрясающе удобно. Можно оперировать одним или несколькими токенами или вообще избавиться от них. Можно сделать процедуру добавления валидаторов гибкой или максимально упростить, добавив «всемогущий» аккаунт. Мощь этой схемы в том, что буквально один разработчик контрактов может создать полную экономику сети на одной платформе с высочайшим уровнем безопасности и переносимости, реализовав сразу и управление сетью, и логику сделок, и другие свойства.
Дополнительное ПО
С Ethereum можно использовать jаvascript-библиотеку web3.js, вне зависимости от консенсуса, валидаторов и ее расположения.
Для POA Ethereum существует репозитарий для автоматизации операций по развертыванию готовой сети — deployment-playbooks.
Если вы планируете запускать POA Ethereum, используйте эту инструкцию. Она проведет вас от создания ключей валидаторов к запуску первых нод, развертыванию системных контрактов и запуску интерфейса валидаторов и обозревателя блоков.
Готовая POA-сеть Ethereum присутствует в AWS, но я все же рекомендую контролировать запуск своими руками. Вы должны понимать, какие сервисы вы запускаете и как они работают.
EOS и его форки
Вторым по гарантиям работоспособности и безопасности будет EOS. “OS” в его названии появилась не случайно.
EOS можно запустить в качестве отдельной сети, в PoS- или PoA-варианте. Как и Ethereum, это ПО уже проверено в бою, обладает высокой безопасностью и функционалом, который позволяет запустить собственный блокчейн со смарт-контрактами для автоматизации любых сделок
Если Ethereum имеет простую систему адресов, то в EOS сразу же используется иерархическая система аккаунтов и права на различные действия. Все это делает EOS похожей по дизайну на операционную систему — «программу для запуска других программ».
В качестве межкорпоративной платформы EOS позволяет из коробки получить удобную систему управления аккаунтами и быстрый консенсус, а также легко интегрировать практически любой функционал при помощи плагинов на C++ и смарт-контрактов на C++/WebAssembly (например, можно добавить другую криптографию).
Дизайн консенсуса в EOS и быстрые блоки позволяют достичь очень быстрого времени ответа пользователю, что крайне важно для построения децентрализованных приложений со сложным функционалом (например, проекты Cyberway, Golos.io или соцсеть Commun). Cyberway недавно произвел сложнейшую миграцию всей бизнес-логики из предыдущего блокчейна прозрачно для пользователей, что лишний раз доказывает гибкость и универсальность EOS.
Код блокчейн-ноды и консенсус
Код EOS написан на C++ и развивался на основе опыта, полученного разработчиками при работе над движками Graphene, Bitshares, Steemit. Используется собственный вариант DPoS-консенсуса.
Сейчас почти все проекты, использующие DPoS, строят свои алгоритмы очень похожим на EOS образом: это аккаунты, «голосующие» балансом токена за топ валидаторов. Валидаторы подписывают блоки по одиночке, но каждый в назначенный квант времени, согласно расписанию. Затем они коллективно фиксируют так называемый Last Irreversible Block (LIB), на котором собирается 2/3 + 1 подписей от валидаторов.
Многие форки EOS пытаются улучшить это консенсус. Например, наш вариант Haya использует для фиксации LIB другой finality gadget — RANDPA, чтобы достичь времени финальности в 2-3 секунды.
Переход к корпоративному POA-консенсусу не вызывает затруднений, так как список валидаторов управляется системными смарт-контрактами.
Смарт-контракты и управление сетью
Смарт-контракты в EOS используют модифицированную виртуальную машину WebAssembly, обычно пишутся на языке C++ и могут создаваться и использоваться любым аккаунтом. Писать смарт-контракты не сложно, во многом они перекликаются с Solidity.
В EOS, как и в POA Ethereum, управление сетью, основной токен (или токены) и типы транзакций можно реализовать в системных смарт-контрактаx (вот, например, системный токен). Интересной особенностью контрактов EOS является использование абстракции table для хранения данных контракта. В Ethereum в основном используется mapping (ассоциативный массив).
Еще одна особенность смарт-контрактов в EOS — upgradeability. Владелец контракта может заменить его, обновив логику или исправив ошибку. Это сильно отличается от Ethereum, где неизменность контрактов — важное условие, гарантирующее, что логика контракта никогда уже не будет изменена, если не произойдет хардфорк.
Для межкорпоративных блокчейнов, на мой взгляд, возможность изменять код контрактов — важное преимущество. Незаметно что-то украсть здесь все равно не получится, зато обновить код по соглашению сторон можно без всякого участия валидаторов.
В EOS возможно организовать «спонсорские» транзакции, оплачиваемые владельцами контракта, а не самими пользователями. Это мощнейшая возможность для привлечения новых пользователей. Вы ведь помните, что «бесплатных» транзакций без потери безопасности в блокчейнах не бывает?
Дополнительное ПО
BOSCore, Telos, Haya и еще десяток форков EOS доказывают, что это ПО интересно большому количеству проектов. Для EOS существует достаточно инструментов, и вам не придется с нуля реализовывать сопутствующее ПО.
Eosjs — аналог web3.js, позволяет работать с контрактами любой сети на базе EOS из браузера и любых приложений.
EOSTracker — обозреватель блоков с открытым кодом и децентрализованными приложениями для голосований за валидаторов.
У EOS нет одного большого и мощного интегратора, как POA Network для Ethereum, поэтому каждый проект строит собственное решение. Тем не менее, основной код ноды стабилен и работает под серьезными нагрузками без сбоев.
Parity Substrate
Substrate создается командой компании Parity. Разработано огромное количество ПО: кошельки, блокчейн-ноды, системы смарт-контрактов, компиляторы, виртуальные машины.
Parity Substrate позволяет разработчику достаточно легко создать свой вариант блокчейна из готовых модулей со сложным консенсусом и логикой обработки транзакций. Substrate — это конструктор блокчейнов, на котором, к примеру, можно сделать блокчейн-ноду Ethereum или биткоина.
Substrate — это часть крупного проекта Polkadot — системы, состоящей из основной цепочки и множества цепочек-шардов с индивидуальной логикой.
Преимущество «подключения» своего блокчейна к Polkadot заключается в возможности ончейн-обмена данными с другими цепочками и возможностью использовать их контракты, аккаунты, токены без дополнительного ПО.
Код блокчейн-ноды и консенсус
Код Substrate написан на языке Rust. На мой взгляд, в структуре Substrate чувствуется большой опыт команды по созданию блокчейнов, так как все компоненты отлично структурированы, разделены на отдельные модули, а в коде присутствуют подробные комментарии. Доказательством гибкости этого движка является существование клиента для сети биткоина и ZCash на основе кода Substrate.
Что касается консенсуса, то можно выбрать из нескольких готовых вариантов или написать свой собственный. В большинстве случаев это PoA или DPoS, что в случае Substrate означает использование алгоритма Aura и GRANDPA.
Производительность блокчейнов на базе Substrate высока. Основная цепочка Polkadot была протестирована нами в конфигурации с 99 валидаторами, распределенными по трем континентам, и показала отличные результаты.
Преимуществом Substrate я считаю продуманность архитектуры, стек разработки (Rust), и огромное поле для развития. Это крайне гибкая сеть, на базе которой можно построить решения любого уровня сложности.
Смарт-контракты и управление сетью
Substrate, в отличие от Ethereum и EOS, обрабатывает транзакции при помощи кода, который размещается валидаторами, а не пользователями. Это код называется “runtime” и исполняется виртуальной машиной WebAssembly.
Напомню, что runtime — это по сути один большой смарт-контракт, который обновляется валидаторами и собирается разработчиком из отдельных модулей. Модули содержат логику аккаунтов, токенов, сделок любой сложности, и т.д. Именно это свойство превращает Substrate в конструктор. Вполне возможно, для решения ваших задач потребуется просто скомбинировать несколько готовых модулей или незначительно доработать один из них.
Особого упоминания заслуживают модули пользовательских смарт контрактов: WASM и EVM. Они дают возможность пользователям размещать свои смарт-контракты, поэтому запуск универсального блокчейна на Substrate тоже возможен.
Ограничения на запуск транзакций реализуются разработчиками runtime — можно сделать все транзакции за одну и ту же цену, учитывать ресурсы с точностью до бита или сделать все бесплатным и вообще не использовать внутреннюю криптовалюту.
В плане гибкости у runtime есть множество преимуществ — разработчик может комбинировать их, создавать сложные роли, объединять управление сетью, внутреннюю логику и экономику. Учитывать следует лишь то, что обновление кода runtime проводится кворумом валидаторов.
Дополнительное ПО
Для Substrate есть ряд полезных решений: polkascan — обозреватель блоков и комплекс программ на JS для работы с Polkadot и сетями на базе Substrate. Возможно, вам пригодятся ansible-сценарии для развертывания готового кластера на базе Substrate, который мы использовали для тестирования Polkadot.
У Substrate нет богатого выбора универсального ПО, кошельков и обозревателей блоков, как у Ethereum или EOS, так как цепочки могут сильно отличаться между собой. Проект активно развивается, и множество команд параллельно создают сопутствующее ПО.
Cosmos SDK
Cosmos — это проект на базе одной основной цепочки и множества дочерних блокчейнов, называемых «zones». Дочерние цепочки строятся на основе Cosmos SDK — набора ПО для построения блокчейнов.
Cosmos — это продолжение проекта Tendermint, из которого ключевыми технологиями является надежный консенсус и концепция Application, сходная с runtime в Substrate.
Как и в случае Polkadot+Substrate, блокчейн, созданный с помощью Cosmos SDK, может жить отдельно или подключиться к экосистеме
Cosmos как дочерняя цепочка.
Весь комплекс ПО Cosmos написан на Go и отлично структурирован и активно используется. На его основе уже работают несколько проектов, среди которых Binance Chain.
Если ваши разработчики пишут на Go — Cosmos SDK может вам подойти. Он работает и активно развивается в реальных проектах, чьи блокчейны и транзакции можно увидеть в публичных сетях.
Код блокчейн-ноды и консенсус
Главная концепция Cosmos называется Application. Любой блокчейн представляет собой машину состояний, и в Cosmos она вынесена в отдельную часть кода.
По сути, разработчик просто задает правила, по которым одни данные превращаются в другие при внешнем воздействии, программируя так называемую функцию state transition. Это сложно звучит, но по факту обработка транзакции — это state transition, которая меняет несколько балансов. Именно этим занимается Application — принимает некоторое воздействие извне (транзакцию) и меняет свое состояние (state). Получившиеся изменения фиксируются в блокчейне. При этом разработчик не должен решать проблемы консенсуса и сети — сеть сама договорится между собой и придет к консенсусу относительно результатов.
Консенсус в Cosmos построен на базе консенсуса Tendermint, крайне близкого к pBFT. Его особенность в том, что подтверждения валидаторов собираются на каждый блок, что означает мгновенную финальность, как только блок принят сетью. Этот алгоритм требует много сообщений между валидаторами, и в случае проблем с сетью этот консенсус будет медленнее финализировать цепочку.
Зато он является наиболее предсказуемым, защищенным от форков, имеет формальные математические доказательства надежности и, по моему мнению, является наиболее строгим и безопасным решением из всех существующих консенсусов.
Смарт-контракты и управление сетью
Application в Cosmos можно рассматривать как единый смарт-контракт, ответственный за обработку всех видов транзакций. Вот пример структуры Application для сервиса регистрации имен.
Одновременно с созданием кода для блокчейн-нод, Cosmos SDK создает код клиента, который умеет формировать транзакции нужных типов.
Для ограничения транзакций в Cosmos, как в Ethereum, используется газ. Исполняя транзакцию, валидаторы вычисляют ее стоимость в условных единицах «gas». Отправляя транзакцию, пользователь указывает цену, которую он готов платить за единицу газа и лимит, который он готов потратить. Это является основанием для вычисления цены за транзакцию.
Важным для Application в Cosmos являются требования к детерминизму кода, т.е. разрабатываемые операции не должны порождать разные результаты в разные моменты времени или на разных архитектурах, иначе блокчейн не будет работать.
Дополнительное ПО
Параллельно с созданием кода Application, Cosmos SDK позволяет сразу же получить код, который вызывает нужные функции с клиентских машин. Этот код можно использовать на сайте, работающем с Cosmos, или в кошельке (клиенте) сети.
На jаvascript я нашел несколько полезных библиотек: js-cosmos, cosmosjs и универсальную js-abci, реализующую интерфейс ABCI. Их удобно использовать, если взаимодействие с вашим блокчейном планируется из браузера. ABCI позволяет создавать Application на разных языках, среди которых Java, C++, Python. Проект lotion, например, позволяет создать блокчейн полностью на jаvascript.
Cosmos бурно развивается, на этом движке запускается много разных проектов. Рекомендую обратить на него внимание, если у вас есть экспертиза в Go и вы хотите надежное работающее решение.
Поднимаем тестовую сеть и оцениваем производительность
Перед запуском основной сети необходимо убедиться в бесперебойности и устойчивости к специфичным атакам. В противном случае исправление допущенных ошибок в децентрализованной среде может обойтись очень дорого.
Чтобы помочь проектам избежать таких ошибок, руководитель отдела исследований MixBytes Сергей Прилуцкий подготовил пошаговое руководство по запуску тестнета и оценки его производительности.
Итак, вы выбрали блокчейн-движок и реализовали первую версию собственного блокчейна. Теперь, чтобы проверить стабильность сети при изменениях, потребуется полномасштабное тестирование. А чтобы будущие пользователи и валидаторы смогли заранее подготовить свои сервисы к реальным условиям, требуется тестовая сеть (или testnet) — максимально полная копия основной сети.
Без тестнета вы не сможете качественно проверить разрабатываемый код, а пользователи не смогут попробовать ваши сервисы в “лабораторных” условиях.
Тестирование и мониторинг блокчейна
Я уже неоднократно писал про тестирование блокчейнов (читайте здесь и здесь), поэтому предлагаю сосредоточиться на практических вопросах. При работе блокчейна в основной сети вы можете столкнуться со множеством проблем, которые стоит решить заранее. Приведу несколько примеров возможных технических проблем:
блокчейн оперирует транзакциями, сохраняющими довольно объемные данные. Запуск и поддержка ноды могут потребовать слишком много места на диске, а стоимость владения нодой для валидаторов быть очень высокой.
вы все правильно оценили, эффективно сжали данные транзакций, и на тестовых машинах разработчиков рост блокчейна стал удовлетворительным. Однако сжатие данных потребовало от нод много ресурсов процессора, что сильно замедлило общую производительность сети.
вы нашли оптимальный баланс между размером и сложностью обработки транзакций, и блокчейн отлично работает на машинах разработчиков. Однако между ними локальная сеть, и после ее запуска в глобальной сети блоки стали передаваться медленно, а скорость сети сильно снизилась.
вы оптимизировали сеть за счет более эффективного консенсуса, но теперь финализация блоков стала отставать.
Продолжать можно бесконечно. И это только верхушка айсберга — ведь еще есть экономические и организационные проблемы. Многие из них можно решить за счет грамотного проектирования и подбора алгоритмов, но лучше использовать комплексный подход.
Поскольку каждая строчка кода исполняется на десятках серверов, даже небольшие изменения могут вызвать каскад последствий и ошибок. Чтобы избежать их, необходимо регулярное тестирование, активный мониторинг и правильная организация работы команды проекта.
Мониторинг
Практически во всех современных блокчейнах предусмотрена возможность подключения внешнего мониторинга для своевременного выявления ошибок. Это не только система уведомлений, сообщающая о критических проблемах, но и сбор важных метрик с нод. Задача системы сбора метрик — проинформировать вас о резких изменениях в одном из компонентов и помочь быстрее найти причину деградации сети.
Необходимо отслеживать как стандартные системные параметры (загрузку процессора и жесткого диска, объем потребляемой оперативной памяти, сетевой трафик), так и специфичные метрики (консенсуса и логики процессинга).
Если вы вносите изменения в сетевой консенсус, то важными метриками будут те, что относятся к его внутренней логике. Для finalitу gadget важно, насколько последний финализированный блок отстал от последних блоков цепочки. Если изменяется сетевой p2p-слой, то полезной метрикой может быть количество активных пиров (peers — равноправные участники сети). Для сложных транзакций можно измерять время и ресурсы, необходимые для того, чтобы упаковать их в блок.
К сожалению, универсального набора метрик не существует. Обязательно добавляйте в мониторинг метрики (например, время процессинга транзакций, или отставание последнего финализированного блока), позволяющие увидеть проблемы в компонентах — так вы сэкономите время и вовремя заметите ошибки. Сделать это несложно, так как во всех современных блокчейн-движках можно отправлять данные на мониторинговые сервера (обычно это комплекс Prometheus + Grafana). Для добавления новой метрики просто скопируйте пару строчек кода.
У вас есть продакт-менеджер, который отвечает за развитие проекта? В случае разработки консенсуса или большой системы контрактов ему довольно сложно отслеживать и оценивать результаты. Зато он может взглянуть на график времени, которое ожидал клиент, пока его транзакция попадет в блок. Мониторинг, метрики и разноцветные графики — это не капризы перфекционистов, а необходимые инструменты для оценки развития проекта. Позаботьтесь о них заранее — облегчите работу коллегам.
Тестирование
С точки зрения тестирования, блокчейны выглядят как базы данных с механизмом репликации типа master-master. Для тестирования распределенных БД существует набор инструкций бенчмарков. Например, TPC или YCSB используют при тестировании новых алгоритмов репликации.
Подобных стандартов для блокчейнов пока не существует. В блокчейне возможно изменить число валидаторов при получении нескольких транзакций (добавить новых или исключить старых). Как я уже говорил, блокчейны — это сети, которые должны оставаться работоспособными при массированных атаках и сговорах, даже если часть валидаторов будет отключена или захвачена атакующими.
Чтобы проверить устойчивость сети под нагрузкой, необходимо запускать тест каждый раз после внесения изменений в консенсус или логику основных транзакций. Например, если в транзакцию добавились новые объемные метаданные или использовался новый алгоритм. При этом важна повторяемость теста — недостаточно просто запустить небольшую тестовую сеть, обновить код на нодах и запустить скрипт, отправляющий транзакции. Без воспроизведения всех начальных условий в тест будут вмешиваться внешние факторы. Хороший пример — дисковый кэш. В первом тесте данные будут считываться и записываться на диск с одной скоростью, а во второй — гораздо быстрее, и вы можете ошибочно принять это ускорение за улучшение производительности блокчейна.
Подбор последовательностей транзакций для теста тоже важен. Например, 1000 транзакций, переводящих некоторую сумму токенов между 2-мя аккаунтами — совсем не то же самое, что транзакции, переводящие токены между 1000 разными аккаунтами. Последние порождают разное поведение памяти, диска и процессора на нодах. Для хороших результатов тестов паттерн должен быть таким, чтобы система могла минимально «помочь» ускорить его в уязвимых местах. Для тестирования платежных транзакций разумно использовать N случайных аккаунтов (каждый раз новых) и транзакции, переводящие случайные количества токенов, а для хранения файлов — файлы со случайным содержимым.
Для блокчейнов и смарт-контрактов лучше всего подходит парадигма «разработки через тестирование» (Test Driven Development или TDD), которая подразумевает постоянное добавление новых сценариев тестирования, и принятие кода только, если он успешно проходит их все. Сценариев взаимодействия — множество, и незначительная ошибка в одном из них может привести к плохим последствиям в другом. Также TDD с первых дней заставит вас заниматься автоматизацией разворачивания блокчейна и сэкономит много времени на последующих этапах.
Автоматизация развертывания тестовой сети
Автоматизация запуска блокчейна «с нуля» позволяет разработчикам и команде проекта:
экономить время на разработку консенсуса.
не тратить время на запуск собственного тестового окружения.
вовремя замечать изменение, «сломавшее» что-то в другой части блокчейна.
проще воспроизводить ошибки, которые повторяются только в специфических условиях.
использовать разработанные сценарии для работы с серверами основной сети в будущем.
Разворачивание блокчейна не сильно отличается от сценариев запуска кластера БД, и местами может быть даже проще благодаря peer-to-peer сети. Вот часть сценариев по развертыванию тестовой сети Polkadot с boot-нодой для массивных тестов производительности сети на основе движка Parity Substrate. Такие же сценарии для тестирования движка Haya сэкономили нам огромное количество времени на запуск сети.
Сценарии для развертывания валидаторов могут требовать жестко прописать peer-id всех валидаторов. Таким образом они никогда не исключат друг друга из списков и в случае проблем с сетью просто дождутся восстановления подключения к сети.
Автоматическое создание аккаунтов
Эту процедуру можно начать на ранних этапах тестирования. В блокчейне потребуется стартовый аккаунт, чтобы с него раздать балансы для тестов, выделить ресурсы или провести процедуры конфигурирования. Обычно для этих задач используются аккаунты самих валидаторов.
Автоматизируя такие задачи, вы неизбежно столкнетесь с необходимостью отправлять в публичные репозитории адреса и приватные ключи валидаторов и тестовых аккаунтов. В этом нет ничего страшного, это даже удобно — ваш менеджер по продукту сможет использовать и показывать инвесторам один и тот же работоспособный кошелек, а все сценарии тестов смогут использовать готовые аккаунты.
Запуск и эксплуатация тестовой сети
Наступает важнейший этап запуска тестовой сети. Проект доказывает, что код работоспособен, сеть может долгое время существовать без остановок, и кто угодно может ее использовать. Этим блокчейны сильно отличаются от централизованных систем — с этого момента скрыть ошибки и недочеты будет сложно.
Для проектов, которые пишут собственный блокчейн без использования существующих движков, запуск тестнета — событие более важное, чем запуск основной сети. Если до этого можно было легко «обнулить» блокчейн и начать с первого блока, то, когда в testnet уже работает часть сервисов, которые изучают тестировщики, аудиторы, внешние команды, это крайне нежелательно.
Для удобного запуска имеет смысл иметь одну или несколько boot-нод с публичными фиксированными адресами. Новые ноды не будут искать в сети ноды тестнета, а обратятся по фиксированным адресам, получат актуальный список пиров и смогут быстро синхронизироваться с сетью. Задача поддержания актуальных boot-нод лежит на команде проекта.
При работе testnet возможен сценарий replay — транзакции «перепроигрываются» всеми нодами, начиная с генезис-блока. Это необходимо, если произошли изменения в логике обработки транзакций и необходимо перестроить состояние всех нод с самого начала, не потеряв транзакции пользователей. В случае критических ошибок этот сценарий возможен и в основной сети, поэтому стоит отладить его в тестовой.
Иногда тестовая сеть может требовать даже большего внимания devops, чем основная. В мейннете проект может держать только одного-двух валидаторов и следить за вспомогательными сервисами. В testnet может потребоваться обновление большого количества нод. В этот момент вам пригодится вся ранее созданная автоматизация обновления ПО.
Запуск testnet также могут провести команды, планирующие строить решения под ваш блокчейн и быть валидаторами вашей сети. Это идеальный вариант, потому что переход от тестовой сети к mainnet будет наиболее простым, без неприятных сюрпризов. Удачи с запуском!
Проводим игру валидаторов
Перед разработкой собственного блокчейна ваша команда должна четко понимать, для чего необходим блокчейн и какой бюджет вы сможете выделить на его содержание.
Проектирование и запуск блокчейна имеют свои нюансы. Их можно легко упустить при планировании, если вы неверно оценили объем и сложность задачи.
Чтобы помочь проектам избежать таких ошибок, руководитель отдела исследований MixBytes Сергей Прилуцкий подготовил пошаговое руководство по запуску блокчейна.
В некоторых блокчейнах валидаторы определены заранее, в других нодами могут владеть независимые люди и компании. Данная статья поможет вам правильно выбрать валидаторов для проекта.
Задачи валидаторов
Валидаторы — главная опора и поддержка вашей сети. Они отвечают за безопасность, и любая атака на блокчейн — это в первую очередь атака на валидаторов. Конечно, вы хотели бы видеть среди них не случайных людей, а специалистов, которые в случае проблем с сетью смогут разобраться в причинах, защитить ноды от атаки, быстро обновить код и помочь разработчикам.
Часто от нового проекта ожидают такое качество документации и поддержки, чтобы любой новичок мог стать валидатором, прочитав инструкцию README на Github. Это хорошо для децентрализации, но плохо для запуска стабильной и качественной сети. Лучше три профессиональных девопса, чем сотня новичков, которые потратят время разработчиков или бросят запуск на полпути. Со временем проект обязательно дорастет до уровня, когда любой сможет легко запустить ноду и стать валидатором.
На этом этапе особенно важно найти хороших валидаторов. А хороший валидатор должен:
уметь собрать и запустить ноду вашего проекта;
уметь оценивать нагрузку на ноду, определять проблемы с производительностью и информировать разработчиков;
уметь закрыть ноду от атаки, вывести ее из-под удара и запустить снова;
иметь автоматические средства мониторинга для решения проблем в режиме 24/7;
вовремя включаться в вопросы управления сетью, оперативно исключать зловредных валидаторов;
быстро обновлять код в случае фикса ошибок;
иметь в запасе готовые сценарии действий в случае типовых проблем.
Поддержка нод аналогична поддержке серверов высоконагруженных сервисов, которые проверяют при помощи нагрузочных тестов и пентестинга. Но имеются и свои нюансы: требуется постоянный мониторинг адресов и балансов валидатора, автоматизированные участия в голосованиях и т.п.
Для успешного запуска сети вам понадобятся несколько десятков опытных девопсов или талантливых новичков, которые смогут самостоятельно запустить ноды и поддерживать их в случае проблем с кодом или внешних атак.
Для этого есть отличная идея, о которой мы узнали от проекта Cosmos: провести игру-соревнование между потенциальными валидаторами, в которой проверяются все вышеописанные навыки.
Игра валидаторов
У специалистов по безопасности есть соревнование, которое называется “Capture The Flag”: команды атакуют сервера друг друга, пытаясь раздобыть секретные “флаги” с серверов противника, одновременно защищая свои.
Игра валидаторов унаследовала этот принцип. Валидаторы соревнуются между собой, чтобы определить, кто сумеет предоставить сети более качественный сервис, чьи ноды более стабильны, кто более устойчив к атакам, кто быстрее реагирует на необходимость обновления кода и т.п.
Этот подход не имеет аналогов в централизованном мире. (Представьте себе группу независимых банков, которые перед запуском платежной системы соревнуются между собой, определяя, кто сумеет провести больше платежей клиентам и не сломаться в случае атаки.)
Блокчейны могут использовать свои токены в качестве награды для валидаторов-победителей. Заработанные в соревновании токены могут быть перенесены в основную сеть, либо команда проекта может пообещать победителям место среди валидаторов основной сети.
Критерии победы
Определить критерии игры сложно, поскольку часть из них невозможно подтвердить в децентрализованном окружении. Валидаторы и команда проекта не знают друг друга, и определить наибольший uptime (% времени, когда сервис был доступен) можно только централизованно. Сервис, измеряющий данные параметры, может быть атакован или ему попросту могут не доверять, а в случае расхождения результатов что-то доказать крайне сложно. Если вы хотите использовать традиционные параметры для оценки качества IT-сервисов, необходимо сразу выбрать судью и смириться с тем, что игроки будут собираться централизованно.
Второй путь — отказаться от любых централизованных метрик и использовать только то, что можно проверить в блокчейне. У этого подхода есть огромное преимущество — результаты игры валидаторов может проверить кто угодно, а оспорить эти результаты — очень сложно.
Одной из самых надежных метрик в этом случае является количество блоков, которые произвел каждый валидатор. Косвенно в этой метрике отражено и uptime валидатора (не могли производить блоки в offline), и количество транзакций (кто произвел больше блоков, обработал больше транзакций), и даже награды (за наибольшее количество произведенных блоков). Число валидированных блоков почти для любых PoS- или PoA-блокчейнов является отличной метрикой, за которую могут соревноваться валидаторы. В случае атак, проблем с кодом, нагрузки сети транзакциями самые оперативные валидаторы смогут произвести и обработать большее количество блоков.
Для игры валидаторов можно использовать и экономические параметры. Например, при изначально равных балансах победителей можно определить по количеству токенов, заработанных за время игры. Если в блокчейне валидаторы зарабатывают на комиссиях с транзакций или существуют дополнительные механизмы получения прибыли (например, реферальная система), их могут использовать для “накрутки” токенов. С другой стороны, валидаторы, которые отправляют транзакции самим себе и на этом зарабатывают, автоматически нагружают всю сеть и заставляют других валидировать свои транзакции. Валидаторы могут самостоятельно “атаковать” сеть, т.е. тестировать в экстремальном режиме, что крайне полезно.
Не стоит забывать, что в алгоритмах консенсуса часть блоков (или все) валидируются и подписываются сразу группой валидаторов. Кроме того, на кону могут стоять серьезные деньги. Например, валидатор может исправить код так, чтобы нода пропускала часть проверок и безоговорочно принимала транзакции. Таким образом, он получит преимущество в скорости перед другими валидаторами и освободит ресурсы. Если в сети только “хорошие” транзакции, такое мошенничество могут не заметить. Поэтому во время игры имеет смысл нагружать сеть также и невалидными транзакциями, чтобы цепочки с блоками, пропущенные нечестными валидаторами, откатывались.
Кто игроки?
Сначала кажется, что чем больше людей смогут участвовать в игре, тем лучше. Вы можете потратить серьезные усилия на привлечение максимального количества участников. Однако этот подход может сработать иначе.
Для PoW-сетей важно иметь максимальное число майнеров любого качества, так как они лишь помогают пулам подбирать хеши блоков. В Proof-of-Stake и Proof-of-Authority отвечают за безопасность данных в блоках, их ответственность гораздо выше, а отключение — проблема.
Если в чатах вашего проекта есть сотни желающих запустить свою ноду, то придется организовать массовую поддержку, тратить время на вопросы от новичков, а самое главное — голосовать за них в сети и раздавать им токены на балансы. При этом эффективно работать смогут лишь несколько десятков валидаторов, а остальные будут приходить и уходить, потеряв надежду попасть в топ списка.
Внимательно подходите к выбору валидаторов, старайтесь привлечь хорошие команды и делайте ставку на качество, а не на количество. Вы также можете заранее подготовить документацию, инструкции, средства мониторинга и автоматизировать операции по стейкингу и голосованиям, чтобы команда могла во время игры валидаторов заниматься транзакциями и кодом, а не тратить время на поддержку.
Конечно, не бывает правил без исключений. Мы сталкивались с ситуациями, когда пара хорошо подготовленных ребят на равных соревновалась с именитыми валидаторами, помогала другим участникам и в итоге получила место в мейннете.
Как проводить?
В игре валидаторов основной дирижер — это команда проекта, поэтому не стоит надеяться на комьюнити, а посвятить почти все время поддержке участников. Обязательно возникнут вопросы, баги, новые требования — и потребуется оперативная реакция.
Для сценария игры нужно определиться с функционалом и заранее описать его валидаторам. При этом, как я упомянул выше, не забывайте о проблеме “ленивого валидатора”. Даже если ваши сценарии звучат заманчиво, это еще не значит, что валидаторы будут активно действовать. Зачастую, им ближе парадигма “работает — не трогай”. Они не будут активно атаковать других валидаторов, оптимизировать ноды и пристально следить за игрой, а просто постараются поддерживать сервера.
Помните, что для валидаторов “игра” — это тысячи долларов, сотни часов опытных девопсов, мощные сервера, исследование нового ПО и поддержка 24/7. Без серьезной награды ни одна компания не выделит серьезные ресурсы, поэтому следует трезво оценивать мотивы валидаторов.
Ниже несколько возможных этапов игры:
1. Нагрузка сети случайными транзакциями
Валидаторы должны быть постоянно загружены обработкой разнообразных транзакций. Для этого команда проекта, которая контролирует токен, создает множество аккаунтов и равномерно распределяет нагрузку между соревнующимся.
Есть и более гибкая стратегия, работающая в DPoS-сетях. В сети размещается контракт-giver (его еще называют faucet), который отдает любому из валидаторов фиксированное число токенов в единицу времени. Валидатор может на постоянной основе обращаться к этому контракту (создавая транзакцию) и использовать полученные токены для продвижения в топе валидаторов. В противном случае через некоторое время его вытеснят более активные участники. Этот подход стимулирует валидаторов постоянно формировать новые транзакции, одновременно нагружая и тестируя сеть.
2. Нагрузка сети невалидными транзакциями
Как я описал выше, нечестные валидаторы могут отключить проверку цифровой подписи транзакций и сэкономить ресурсы CPU, чтобы лучше противостоять большому потоку транзакций. Имеет смысл отправлять в сеть невалидные транзакции — тогда блоки, подписанные нечестными валидаторами, будут отсеиваться честными. Пытаться поймать обманщиков таким путем стоит, только если на кону действительно большие деньги или влияние.
3. Проведение DoS-атак на валидаторов
В данном случае игра будет наиболее полной, а валидаторы столкнутся с самыми серьезными проблемами — им придется уводить свои машины из под атаки, менять IP-адреса, оперативно отсекать трафик атакующих и т.п. Как и в случае с нагрузкой транзакциями, лучше всего, если валидаторы сами будут атаковать друг друга с целью получить преимущество в количестве произведенных блоков. Но для этого девопсам придется на время стать злоумышленниками и использовать ПО для проведения атак. Кроме того, более богатые участники могут использовать купленные облачные мощности и повлиять на ход игры.
Для данного этапа хорошей стратегией будет равномерная атака валидаторов командой проекта. Помните, что подобные действия может обнаружить провайдер, и вам может потребоваться документальное подтверждение факта проведения атаки с целью тестирования.
4. Обновление кода
Обновление кода ноды — штатная задача, которую должен уметь выполнять любой валидатор, поскольку с ним придется столкнуться в основной сети. Эти процедуры могут быть как очень простыми, так и довольно сложными (например, если требуется replay цепочки с нуля).
Лучший вариант — если баг не позволяет производить новые блоки, а исправление — восстанавливает этот функционал. В этом случае те валидаторы, которые быстрее смогли обновиться (а, возможно, и перестроить цепочку с genesis блока) смогут быстрее вернуться к производству блоков и получат преимущество в игре.
5. Другие сценарии
Существует множество сценариев, которые можно включить в игру. Команда проекта может добавить бонусы за действия, полезные для сети: публикацию кода для мониторинга и управления нодами, активность в governance-протоколах и т.д. Все ограничено только вашей фантазией.
Однако помните о “ленивых валидаторах”. Если награждаемые действия требуют сложных взаимодействий или разработки специализированных инструментов, валидаторы вряд ли пойдут на это.
Заключение
Игра валидаторов — это прекрасный способ собрать команду профессионалов, способных обеспечить блокчейну надежную защиту, наградить наиболее подготовленные к трудностям команды и провести яркое маркетинговое мероприятие, которое не имеет аналогов в скучном централизованном мире.
Поднимаем основную сеть
Мы добрались до запуска основной сети (мейннета) проекта. Разработка, тестирование, запуск тестовой сети и выбор валидаторов уже позади. Впереди — раздача реальных балансов токенов участникам и ответственность за безопасность значительных сумм.
В данной статье руководитель отдела исследований MixBytes Сергей Прилуцкий расскажет о нюансах запуска основной сети.
Наиболее важные шаги для технической команды — запуск тестнета и игры валидаторов — завершены, и к этому моменту сеть должна быть технически готова. К сожалению, «децентрализованная сеть» вовсе не означает, что все запустится автоматически. Запуском основной сети придется активно заниматься команде, которая отвечает за код блокчейна.
Genesis и начальное состояние
Genesis-блок — первый блок основной сети. Проще говоря, он содержит всю начальную информацию: стартовые балансы, код основных смарт-контрактов, список первоначальных валидаторов.
На деле блоки не содержат данные, а только хеши состояний. Для большинства блокчейнов стартовое состояние — это сразу несколько файлов, часть из которых является снапшотом базы данных. Именно с него начнется жизнь базы данных состояния блокчейна на всех нодах сети. Любая нода основной сети обязана стартовать цепочку именно с этих данных, иначе весь блокчейн будет невалидным.
На старте у команды есть список адресов или публичных ключей тех, кто получит на баланс токены, и код основных контрактов. Список может меняться вплоть до последних часов перед запуском, поэтому имеет смысл сделать скрипт, который из списка адресов-балансов создает начальное состояние (genesis-блок и все необходимое). Скрипт может выводить на экран все адреса и информацию о начальном состоянии, а его запуск можно транслировать в онлайн-режиме на Youtube.
Так вы сможете задокументировать запуск, а повторить эту операцию сможет любой пользователь, который сомневается в честности распределения стартовых балансов или содержимом контрактов.
Старт производства блоков
Для старта производства блоков требуется участие нескольких валидаторов. Некоторые из них могут столкнуться с проблемами: часть команд может перепутать конфигурации тестовой и основной сетей, другая — использовать устаревшее начальное состояние, третья — неправильно оценить ресурсы серверов и т.д. Поэтому не стоит пугаться, если новые блоки вы увидите не сразу.
Наберитесь терпения или проектируйте запуск так, чтобы подключение новых валидаторов было постепенным. Например, запустите сеть на своих машинах, постепенно уступая места новым валидаторам, или подключите небольшое число валидаторов на старте сети и увеличивайте его по мере добавления новых.
Советую заранее подготовить скрипты, которые выводят список работающих валидаторов, а также чек-лист для их самопроверки.
Аккаунты валидаторов
Каждый валидатор сети имеет аккаунт, который используется для подписи блоков, голосований за других валидаторов и других важных функций. Для работы валидатора приватные ключи располагаются на сервере валидатора.
Этот сервер может быть атакован несколькими способами — от атаки на ПО валидатора до атаки на аккаунты девопсов, поэтому нужно использовать ключи, получение которых не позволит атакующему контролировать средства валидатора. Например, в DPoS консенсусах на адресе валидатора нет криптовалюты, но за него «голосует» другой адрес с отдельной машины. В случае взлома валидатора, можно запустить другого и переголосовать за него. Отличной практикой является передача вознаграждений за валидаторство на независимый внешний адрес.
Отдельно нужно отметить роль мультисиг-адресов (см. статью). Они являются обязательными, поскольку взлом любого из мультисиг-адресов не будет фатальным. Для полного доступа к средствам нужно получить доступ к нескольким (минимум двум) приватным ключам вместо одного (количество необходимых подтверждений может меняться).
Примером мультисиг-активности может быть участие в «выборах» валидаторов, для которых требуется стейкинг средств на смарт-контракте, выбирающем валидаторов. Сервер валидатора раз в сутки отправляет транзакцию-заявку, но она не является действительной, пока с другого адреса не будет отправлена транзакция-подтверждение. Подтверждение отправляется с любой независимой от валидатора машины, взлом которой также не даст полного доступа к средствам валидатора.
Несмотря на мощную защиту, многие валидаторы не любят мультисиг-логику, так как это дополнительные сервисы, за которыми нужно следить. Для подобной деятельности обычно используются скрипты, которые автоматически мониторят нужные валидатору адреса и подтверждают необходимые транзакции.
Подобное ПО обязательно должно проверять как минимум адрес, которому адресована подтверждаемая транзакция или тип вызываемой функции смарт-контракта. Без подобной проверки злоумышленник может создать транзакцию, выводящую средства с адреса валидатора, а скрипт автоматически подтвердит и подпишет ее дополнительным ключом — в этом случае защита с помощью мультиподписи теряет смысл.
Режим бога
Не всегда при запуске блокчейна можно быть уверенным, что все пойдет как надо. Возможно, вы захотите изменить системные смарт-контракты в первые месяцы существования сети или вам придется дорабатывать сеть на ходу из-за требований со стороны бизнеса.
Вам также может потребоваться оперативно вносить изменения в системные контракты без сложных процедур согласования. В этом случае допускается создание специальных «всемогущих» аккаунтов, которым разрешено менять код системных контрактов и иметь доступ к аккаунтам участников. В этом случае имеет смысл заложить и публично продемонстрировать логику, которая отключит этот функционал после определенного времени и повысит уровень доверия к сети.
Не рекомендуется оставлять такие аккаунты надолго, особенно после появления токена сети на биржах или его доступности для обмена — в этот момент возможна организация атак, способных полностью подорвать капитализацию сети.
«Всемогущий» аккаунт — заманчивая цель для атаки, способной нанести серьезный ущерб сети даже в корпоративных блокчейнах .
Мосты
Часто токены проекта сначала выпускаются в сети Ethereum, а для создания своего токена требуется лишь несколько несложных действий в браузере. Только после запуска основной сети держатели токенов могут перенести свои балансы в запущенную сеть. ПО, используемое для переноса токенов из одного блокчейна в другой, получило название «мосты».
Мост между двумя блокчейнами — это сервис, который мониторит одновременно обе сети. Когда пользователь хочет переместить токены, мост «забирает» их в исходной сети и «выдает» в требуемой.
Мосты могут быть однонаправленные (перемещают токены только из одной сети в другую), либо двунаправленные (перемещают токены в обоих направлениях). Механика работы мостов может быть очень разной в зависимости от того, какие виды смарт-контрактов поддерживают обе сети.
В большинстве случаев операторами мостов являются валидаторы сети. Они принимают токены вашего проекта в Ethereum на специальный смарт-контракт, и, убедившись в их получении, выдают соответствующую сумму токенов в вашем блокчейне и в обратном направлении.
Для сетей на базе Ethereum, EOS или других с полноценными многофункциональными смарт-контрактами существуют универсальные имплементации мостов (пример) или проверенные алгоритмы действий.
Мост с биткоинподобными сетями — это гораздо более сложная задача из-за UTXO-дизайна адресов.
Мосты должны быть спроектированы заранее и протестированы на этапе тестнета.
Мониторинг
В децентрализованной сети валидаторы отвечают за мониторинг и следят за работоспособностью своих серверов. Команда проекта, в свою очередь, тратит ресурсы на поддержку только своих валидаторов. Нужно ли собирать мониторинговую информацию со всех валидаторов сети и самим платить за поддержку серверов мониторинга?
Решать вам — для мониторинга в основной сети вам понадобится лишь пара дополнительных серверов для централизованного сбора метрик с валидаторов, а польза от этого сервиса довольно велика — все участники смогут получать общую, агрегированную информацию о работе сети.
При запуске вашей команде будет поступать большое число вопросов: какие валидаторы активны, корректно ли они работают, какова их производительность по сравнению с коллегами? Стоимость этих не очень требовательных серверов, возможно, окупит рабочее время ваших специалистов.
Не обязательно постоянно поддерживать этот сервис — вы в любой момент можете выключить его, а валидаторам будет достаточно запустить собственную копию и изменить пару адресов, чтобы запустить собственный мониторинг.
Дополнительное ПО
Обозреватель блоков
Без сомнения, это важнейший сервис блокчейна, отображающий информацию о блоках и транзакциях. Однако на этапе запуска транзакций и адресов крайне мало, и по сравнению с тестнетом или с игрой валидаторов обозреватель блоков не сильно интересен участникам на начальных этапах. Большинство активно работающих аккаунтов — это валидаторы и разработчики, которые предпочтут использовать различные специализированные утилиты для получения нужной информации.
Создание качественного и удобного обозревателя блоков основывается в первую очередь на опыте пользователей — а его пока крайне мало. Работать этот сервис должен, но на старте сети не требует чрезмерного внимания.
Портал валидаторов
В первые недели жизни сети портал для валидаторов крайне важен, так что я рекомендую потратить на него время и добавить хотя бы простейшую агрегацию данных. Например, uptime валидаторов, количество произведенных блоков, статистика по стейкингу, голосованиям и наградам валидаторов.
Предоставив участникам возможность проверять и контролировать себя, вы быстрее увидите потенциальные проблемы и сможете точнее отвечать на любые вопросы, касающиеся экономики сети.
Утилиты командной строки
Если нужно, чтобы валидаторы с первых запусков могли автоматизировать основные задачи, определять проблемы и реагировать на них — обязательно нужны утилиты, которые позволяют проводить голосования, узнавать статус валидатора, подтверждать multisig-транзакции и т.п.
Кажется, что обеспечить качество этого вида ПО намного проще, чем сделать хороший обозреватель блоков или кошелек. Однако на практике частые изменения в коде будут ломать схемы автоматизации на стороне валидаторов, что может привести сеть к неприятным сбоям и конфликтам.
Внимательно отнеситесь к этим инструментам, старайтесь не переименовывать параметры и их формат «для красоты» после запуска и жестко следуйте стандартам, принятым в разработке свободного ПО. По качеству именно этого ПО валидаторы будут судить о степени подготовки вашей команды.
Кошелек и основные приложения
Ради работы этого ПО и затевался блокчейн. К моменту запуска мейннета каждый пользователь на вес золота, поэтому любое исправление в коде кошелька или основного децентрализованного приложения сети должно быть быстрым. Для этого нужно отладить весь цикл выкатки кода еще в тестнете, добавить подробный мониторинг и бороться за каждого пользователя.
http://forklog.com/ (C)
Не является индивидуальной инвестиционной рекомендацией
При копировании ссылка обязательна Нашли ошибку: выделить и нажать Ctrl+Enter