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

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

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

Чтобы помочь проектам избежать таких ошибок, руководитель отдела исследований 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) — это веб-стандарт, используемый для создания кода, исполняемого на стороне клиента и более производительного, чем JavaScript. Теоретически, смарт-контракты под 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 или базу данных с критичной информацией без регистрации, логинов/паролей и мониторинга не представляется возможным.

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

Подписывайтесь на новости ForkLog в Telegram: ForkLog Feed — вся лента новостей, ForkLog — самые важные новости и опросы.