ГЛАВНАЯ / ИНСТРУКЦИИ / BATCH POSTER И PROPOSER ROLLUP: КТО ПУБЛИКУЕТ ДАННЫЕ И STATE COMMITMENT
Batch poster и proposer rollup: кто публикует данные и state commitment
Один актор rollup может отправлять сжатые транзакционные данные на L1, а другой – заявлять итоговое состояние L2. За эти действия отвечают разные функции: batcher или batch poster публикует batch, proposer подаёт output или assertion. Названия и сочетание ролей меняются между сетями.
Batcher отправляет данные, из которых выводится история L2
Batch poster собирает или отправляет пакет сообщений, необходимых узлам для деривации истории L2. В OP Stack batcher публикует frames в настроенный inbox, а rollup node извлекает их из L1 и собирает batches. В Arbitrum batch poster отправляет сжатые данные в Sequencer Inbox. Форматы и правила авторизации отличаются.
Проверьте получателя L1-транзакции, batcher identity, номер эпохи и доступность payload. L2-блок может появиться в soft feed раньше, чем соответствующие данные окажутся в финальной записи parent chain; проверьте, на какой стадии находится конкретное подтверждение.
- зафиксировать сеть и конкретный блок, а не только имя проекта;
- сопоставить термин интерфейса с определением протокола;
- сохранить L1-запись и источник L2-данных.
Proposer подаёт commitment или assertion на settlement layer
В OP Stack proposer публикует output root с данными блока для settlement и L2-to-L1 сообщений. В Arbitrum validator может предложить assertion о состоянии в Rollup-контракте; утверждение может быть оспорено. В иных сетях термины proposer, validator и sequencer покрывают свои сочетания функций.
Proposal не заменяет транзакционные данные. И наоборот, опубликованный batch не доказывает сам по себе, что state root верен. Найдите контракт, высоту блока и статус proof или challenge.
- проверить адрес контракта и событие публикации;
- отличить commitment от payload или завершённого proof;
- учесть версию и конфигурацию сети на нужной высоте.
| Функция | Что отправляется | Что проверять |
|---|---|---|
| Batcher/batch poster | Frames или сжатые транзакции | Inbox, sender, epoch, DA |
| Proposer/validator | Output root или assertion | Контракт, высота и проверка |
| Sequencer | Порядок и soft-блоки | Soft confirmation и L1 batch |
| Settlement contract | Принятие, спор, выход | Версия протокола и финальность |
Один оператор может обслуживать несколько ролей
В реальной инфраструктуре один оператор или связанная команда могут использовать отдельные ключи для batcher, sequencer и proposer. Это не делает функции одной протокольной ролью: одна публикует входы, другая задаёт порядок, третья предлагает commitment. Настройки ключей и полномочий тоже могут изменяться независимо.
Сопоставляйте роль с контрактным действием, а не только с названием организации. Для OP Stack смотрите system configuration и batcher identity нужного L1 origin; для Arbitrum – события Sequencer Inbox, batch и assertion. Один адрес не доказывает ни независимость, ни централизацию всей системы.
Сопоставьте batch, L2-блок и commitment
Для нужного L2-блока установите L1 origin и найдите транзакцию с batch. Проверьте данные нужной эпохи. Затем найдите output proposal или assertion, сравните высоту и commitment с L2 header и проверьте, завершилось ли оспаривание.
Сохраните отдельно L1 receipt публикации входов и L1 запись state commitment, добавив chain ID, block hash и адреса контрактов. Данные могут быть опубликованы, пока output ещё не подан; commitment может быть подан, но ещё не окончателен. Эти независимые статусы помогают локализовать задержку.
Частые вопросы
Batch poster и proposer – один участник?
Один оператор может обслуживать оба действия, но это разные функции и записи.
Публикация batch подтверждает state root?
Нет. Она публикует входы; состояние проверяется отдельно.
Proposer отвечает за порядок транзакций?
Не обязательно. Порядок обычно задаёт sequencer; функции зависят от архитектуры.
Как узнать, кто отправил batch?
Проверьте L1 sender, inbox и configuration соответствующего блока.
Почему обозреватель показывает разные статусы?
Публикация batch и проверка commitment проходят раздельно.
Чек-лист: batch poster и proposer rollup: кто публикует данные и state commitment
- L2 и L1 origin определены;
- batch transaction найдена и привязана к эпохе;
- payload доступен по правилам DA;
- output/assertion найден отдельно;
- роли сверены с контрактами и ключами;
- статусы публикации и проверки разделены;
- название оператора не заменяет анализ транзакции.
Материал подготовлен редакцией сайта и проверен 29 октября 2026 года. Условия бирж, кошельков и блокчейн-сетей могут меняться. Перед операцией сверяйте данные в интерфейсе выбранного сервиса.