Развёртывание кастомного Blockscout для EVM-сетей

Развертывание Blockscout для сети: где теряются данные

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

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

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

Эффект: скорость поиска, полнота истории, контроль доступа

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

• Скорость поиска по сети. Ответ по адресу, хешу транзакции или номеру блока — доли секунды на прогретом кэше, без очереди к публичному сервису и зависимости от чужой нагрузки.
• Полнота индексации переводов. Внутренние переводы, вызовы контрактов и события токенов попадают в базу целиком — история и балансы сходятся с состоянием сети, а не ограничиваются внешними транзакциями.
• Разгрузка узлов сети. Тяжёлые выборки истории уходят в отдельную базу обозревателя, и точки доступа перестают держать пиковую нагрузку от аналитики и выгрузок.
• Контроль доступа к обозревателю. Роли настраиваются под задачу: публичный просмотр, закрытый контур для аудита, отдельные права на выгрузку данных и экспорт.
• Кастомный обозреватель блоков. Свои фильтры, поля и подписи для внутренней логики сети — то, чего в публичном сервисе не покажешь.

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

Как разместить обозреватель: облако, свои серверы, гибрид

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

Мы разворачиваем Blockscout и его форки в трёх режимах — от полностью управляемого до полностью своего. Разница между ними не в «удобстве», а в том, какие ограничения вы принимаете осознанно.

Выбор режима — не вкусовщина, а следствие требований к данным и нагрузке. Дальше показываем, как переносим индекс между контурами без потери истории.

Как проходит развертывание Blockscout: этапы внедрения

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

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

2. Подготовка окружения. Поднимаем узлы нужного режима, базу под данные индексатора, прокси-слой с шифрованием трафика, разграничение доступа по сетям. Заранее описываем схему отказоустойчивости: что переживёт перезапуск, а что придётся досинхронизировать.

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

4. Синхронизация и сверка данных. Выборочно сравниваем блоки, балансы адресов и внутренние переводы с данными узла, ищем пропуски и дубли. Отдельно смотрим, как ведёт себя индексатор после перезапуска — подхватывает ли он хвост без ручного вмешательства.

5. Проверка под нагрузкой. Прогоняем поиск по адресам, фильтры событий и выгрузки на потоке запросов, измеряя отставание индексатора от головы сети. Если на пике отставание растёт, добавляем ресурсы до приёмки, а не после.

6. Приёмка обозревателя. Проходим по сценариям: поиск по хэшу, верификация контракта, история токенов, корректность внутренних переводов. Заказчик получает чек-лист с результатами по каждому пункту.

7. Передача доступов. Отдаём роли и ключи, доступ к базе и мониторингу, метрики по отставанию и ошибкам индексации, инструкцию по восстановлению после сбоя.

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

Комплект поставки: конфигурации, схемы, регламенты

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

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

Кейс: обозреватель для растущей сети, метрики до и после

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

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

Развернули собственный Blockscout рядом с сетью: индексатор читает блоки напрямую и пишет в нашу базу от генезис-блока, интерфейс отвечает из локального кеша, тяжёлые выборки не доходят до узлов.

Метрики до и после

Что это дало

Узлы перестали быть узким местом: нагрузка от публичного обозревателя ушла в отдельный контур чтения, и кошельки снова отвечают без очереди. Добавили метрики состояния индексатора — отставание от головы цепи, глубину очереди, время ответа, — по ним видно деградацию раньше, чем её заметят пользователи.

Чем отличается свой обозреватель от готового у вендора

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

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

Доступ к исходным данным сети — второе отличие. Вендорский вариант отдаёт срез через чужой API с лимитами на частоту запросов и выгрузку, нередко без сырых логов и внутренних транзакций. Свой экземпляр открывает полный набор — для аналитики, разбора спорных операций и отчётности.

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

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

Технические сомнения: нагрузка, доступы, обновления

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

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

Как разделяются доступы?

Читатель только смотрит, оператор видит метрики и журналы без прав на запись в базу, администратор работает через отдельный контур доступа. Учётные записи выдаются поимённо, ключи ротируются, общий логин не используется.

Как обновляется обозреватель без потери данных?

Компоненты обновляются по очереди: сначала веб-часть, затем индексатор. Изменения схемы базы применяются пошагово, а предыдущий образ остаётся доступным для отката. Простой в момент переключения измеряется минутами.

Кто отвечает за резервные копии и безопасность?

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

Что прислать, чтобы мы вернулись с планом и оценкой

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

• Параметры сети: chain id, тип — собственная EVM-сеть, rollup или sidechain, режим консенсуса, адреса системных контрактов.
• Доступ к узлам: RPC- и WebSocket-эндпоинты архивирующего узла, учётные данные, площадка под обозреватель и её ограничения.
• Нагрузка и история: число транзакций в сутки, глубина индексации — с нулевого блока или с определённой высоты, нужны ли внутренние транзакции и логи.
• Функциональность под задачу: верификация контрактов, страницы токенов и адресов, открытый API, кастомный интерфейс, роли модератора — от этого зависит объём работ.
• Текущее состояние: работает ли обозреватель сейчас, нужно ли переносить проиндексированную базу и сохранять старые адреса и ссылки.
• Команда и доступы: кто передаёт узлы и доступы с вашей стороны, кто принимает результат, в какие окна можно проводить работы.
• Сопровождение: какие события критичны, нужны ли алерты и регламент обновлений для сопровождения обозревателя.

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