blockchain

Основная сеть запущена, транзакции отправляются, кошелек работает. Что дальше?

В данной статье руководитель отдела исследований MixBytes Сергей Прилуцкий рассмотрит, как поддерживать сеть и решать проблемы в процессе эксплуатации.

Обновление кода

Чем моложе мейннет, тем больше исправлений потребуется, а чем старше — тем больше ответственность за каждое изменение.

Обновление кода базового проекта

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

Именно теперь придется платить: чем больше изменений вы внесли, тем больший объем работы нужно будет проделывать каждый раз, когда потребуется перенести изменения из базового проекта в ваш.

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

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

Replay цепочки

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

Полный replay цепочки — это крайне затратно и долго. Придется повторить все операции нод за время жизни проекта.

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

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

Сценарий replay-цепочки должен быть отлажен до запуска основной сети и стать для команды знакомой задачей.

Структура и оптимизация сети

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

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

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

Доступ «на чтение» несложно масштабируется, так как ноды одинаковые, и почти все используют хорошо знакомые стандарты JSON REST API и WebSockets.

С доступом «на запись» все несколько сложнее — нужно думать о том, какие валидаторы первыми получат новые транзакции так, чтобы весь поток не шел через один сервер. Поэтому в клиентском ПО (например, кошельке) должны быть прописаны адреса сразу нескольких зарезервированных серверов.

Особенности владения инфраструктурой

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

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

Валидаторы и виды нод

С точки зрения потребления ресурсов и стоимости владения интересны следующие моменты:

Подписи

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

Заголовки

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

Сеть

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

Память

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

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

Если на простом и дешевом VPS-сервере у вас все работает — дождитесь счета, в котором учитывается трафик и дисковые операции (IOPS). Возможно, вас ждут неприятные сюрпризы.

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

Для валидаторов сети и полных нод более выгодно использовать обычные, железные сервера, а не VPS. Они стоят дешевле, не нужно отдельно платить за операции с диском, а отказ диска доставляет немного проблем. В подавляющем числе случаев паттерн работы диска — «append only», т.е. блокчейн всегда дописывает новые данные, а большинство обновлений происходит в оперативной памяти. Такой паттерн продлевает жизнь современным SSD-дискам, которые теряют ресурс из-за активной перезаписи при переполненном диске.

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

Самым нагруженным сервисом с наибольшим числом компонентов в сети является обозреватель блоков. Он состоит из нескольких довольно сложных компонентов:

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

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

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

Кошелек — это легковесное ПО с рядом особенностей. Во-первых, кошелек управляет приватными ключами пользователей. Для хороших кошельков должны соблюдаться самые строгие меры обеспечения безопасности. Например, приватный ключ или seed-фраза должны находиться в оперативной памяти только в момент подписи транзакции, когда они не используются, так как другой процесс может прочитать их из памяти (если получит нужные полномочия).

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

Я рекомендую регулярные аудиты этого ПО независимыми компаниями и аккуратное добавление нового функционала.

Системные смарт-контракты

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

К системным смарт-контрактам можно отнести:

• контракт основного токена системы (например, ETH). Это точно такой же токен, как любой ERC-20, но его адрес навсегда вписан в блокчейн Ethereum.
• контракты-библиотеки предоставляют доступ к важным функциям блокчейна с самого начала. Например, с помощью системного смарт-контракта пользователи создают мультисиг-адреса. Это базовый примитив, с помощью которого валидаторы могут голосовать за что-либо, защищать инфраструктуру от взломов, надежно хранить заработанную криптовалюту.
• контракты governance управляют списком валидаторов, размером их наград, изменяют глобальные системные параметры (например, максимальное число транзакций в блоке, время между блоками, и т.п.). Обычно в них настраивается экономика сети, поэтому надо быть готовым к изменениям.
• контракты мостов. Обычно это мультисиг-контракты, которые позволят выпустить X токенов сети при достижении кворума валидаторов. Валидаторы подтверждают операцию, только если видят передачу токенов из внешней сети. Этот вариант мостов наиболее популярен, прост для пользователей и требует точно того же доверия к валидаторам, как и ко всему блокчейну.

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

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

На заметку

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

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

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

Многое зависит от community-менеджера, его активности и умения координировать действия множества совершенно разных людей. Разработчикам и девопсам придется ответить на множество вопросов, поэтому не забудьте завести раздел FAQ и оперативно его обновляйте.