Интеграция с Celestia: модульная DA для вашего rollup

Интеграция Celestia: где роллап теряет доступность данных

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

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

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

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

Что даёт вынос данных в отдельный слой

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

Скорость и стоимость публикации

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

Класс отказов, который уходит

Раньше rollup и основная сеть делили одну полосу: всплеск активности в соседнем приложении раздувал комиссии и откладывал публикацию. Модульная доступность данных разводит потоки — снижение нагрузки на основную сеть измеряется долями от прежнего объёма, а вывод состояния не встаёт из-за перегрузки одного сегмента.

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

Когда интеграция Celestia оправдана: сравнение схем данных

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

На что смотреть при выборе схемы

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

Этапы внедрения: от аудита до передачи в поддержку

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

Аудит текущего контура и схема решения

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

Настройка, проверка на отказах и передача регламентов

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

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

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

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

Комплект документации

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

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

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

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

• Доля блоков без подтверждённой доступности: 3–4% в пиковые сутки → меньше 0,1%. Подтверждение стало шагом конвейера, а не отдельной операцией, которую кто-то запускает вручную.
• Время восстановления после сбоя: 30–40 минут сверки и докатки состояния → около 10 минут. Нода поднимается из внешнего слоя по сохранённым обязательствам, без обращения к дежурному инженеру.
• Объём реестра данных: сократился примерно втрое. Полезная нагрузка ушла во внешний слой, в собственном хранилище остались обязательства по блокам и окно, достаточное для разбора спорных ситуаций.

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

Чем модульный слой данных отличается от архива и реплики

Три механизма решают три разные задачи и совпадают ровно в одном: каждый хранит копию чего-то. Архив фиксирует историю, реплика повторяет текущее состояние, модульный слой данных подтверждает доступность. Как только роли смешивают, в архитектуре появляется уверенность, которая ничем не подтверждается.

Архив отвечает на вопрос «что было»: он отдаёт исторические блоки и нужен для разбора инцидентов и пересборки состояния. Быстрым он быть не обязан — и не обязан отдавать свежие данные. Если узел потерял последние блоки, архив этому никак не мешает.

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

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

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

Технические сомнения перед стартом

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

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

Можно ли перейти без остановки сети?

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

Как вы проверяете доступность данных?

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

Совместимо ли это с существующим контуром?

Меняются конфигурация сборщика и точка публикации данных; логика состояния и контракты rollup остаются как есть. Для другого стека описываем переходный слой и объём правок до старта.

Кто отвечает за доступность?

Границы фиксируем документом: мы отвечаем за сборщик, публикацию и мониторинг со стороны rollup, внешний слой — за его провайдера. Метрики, алерты и пороги дежурства передаём вместе с конфигурацией.

Что уточним перед оценкой и планом внедрения

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

Что нужно от вас на входе:

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

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