ГЛАВНАЯ / ИНСТРУКЦИИ / FORCED INCLUSION В ROLLUP: КАКИЕ ГАРАНТИИ ДАЁТ МЕХАНИЗМ
Forced inclusion в rollup: какие гарантии даёт механизм
Forced inclusion – резервный путь для сообщения, которое обычный sequencer не включил. Пользователь передаёт данные через контракт родительской сети; после заданного протоколом ожидания запись может продвинуться без sequencer. Механизм, сроки и ограничения различаются – сначала изучите документацию конкретного rollup.
L1-контракт сохраняет запись для деривации L2
Типовая схема содержит inbox или deposit contract, очередь ожидания и процедуру, которая делает сообщение доступным для вывода состояния L2. В Arbitrum документация описывает Delayed Inbox и вызов forceInclusion после force-inclusion window. В OP Stack L1 deposits включены в правила деривации, а sequencing window задаёт диапазон L1-блоков для обработки данных. Это разные реализации, даже если их назначение похоже.
Проверьте адрес контракта, chain ID, допустимую функцию, авторизацию и событие регистрации. Очередь на L1 ещё не означает, что L2 уже обработала транзакцию: узел должен вывести состояние по правилам сети и включить сообщение в блок.
- зафиксировать сеть и конкретный блок, а не только имя проекта;
- сопоставить термин интерфейса с определением протокола;
- сохранить L1-запись и источник L2-данных.
Срок зависит от параметров и может считаться в блоках
Не полагайтесь на универсальное число часов. Механизм может считать L1-блоки, использовать переменный delay buffer или sequencing window. Для Arbitrum One документация описывает расчёт срока через параметры Sequencer Inbox и отдельную функцию deadline; это значения именно этой конфигурации, а не всех rollups.
Проверьте официальный контракт или конфигурацию для текущей высоты и пересчитайте deadline непосредственно перед вызовом. Остановка родительской цепи или реорганизация L1 влияет на продвижение и видимость очереди.
- проверить адрес контракта и событие публикации;
- отличить commitment от payload или завершённого proof;
- учесть версию и конфигурацию сети на нужной высоте.
| Проверка | Что подтвердить | Зачем |
|---|---|---|
| Контракт | Inbox/deposit на parent chain | Не отправить в похожий адрес |
| Ожидание | Блоки, буфер или sequencing window | Не считать срок общим для L2 |
| Доступ | Allowlist и pause | Путь может быть ограничен |
| Сообщение | Поддерживаемый тип и параметры | Не каждый payload пройдёт |
| Результат | L2 block и receipt | Очередь не равна исполнению |
Включение не отменяет проверку подписи и исполнения
Forced inclusion помогает преодолеть цензуру sequencer в пределах правил inbox. Но сообщение могут отклонить из-за неверного chain ID, nonce, недостатка баланса или параметров комиссии; включённый вызов может завершиться revert и потратить газ. Перед подачей сверьте nonce, fee cap, gas limit и баланс.
L1-вызовы могут требовать отдельных комиссий. Контракт может иметь allowlist или pause. В некоторых системах продвижение очереди меняет порядок канонических данных и вызывает reorg блоков, подтверждённых только soft feed. Изучите документацию и последствия именно этой сети.
Сначала подтвердите L1-запись, потом результат L2
Сохраните параметры исходного сообщения. Найдите L1 receipt и событие inbox с идентификатором сообщения; убедитесь, что транзакция достигла нужного уровня подтверждения. Рассчитайте доступность вызова по официальной функции. После продвижения найдите соответствующий L2-блок и receipt.
L1 message hash и L2 transaction hash могут быть разными. Сопоставьте sender, nonce, calldata и идентификаторы source. Если receipt не появился, проверьте, дошло ли сообщение до derivation и прошло ли pre-execution validation; не повторяйте отправку вслепую.
Частые вопросы
Все rollups поддерживают forced inclusion?
Нет. Наличие и условия проверяют по документации конкретной сети.
Механизм гарантирует успешную транзакцию?
Нет. Включение не отменяет проверку параметров или revert.
Можно ориентироваться на срок в старой инструкции?
Только после проверки актуальной конфигурации; задержка может считаться в блоках и меняться.
Сообщения в L1 inbox достаточно?
Нет. Нужно подтвердить продвижение и исполнение в L2.
Возникают отдельные комиссии?
Могут быть расходы parent chain и L2 по правилам конкретного сообщения.
Чек-лист: forced inclusion в rollup: какие гарантии даёт механизм
- путь подтверждён для выбранного rollup;
- адрес и функция inbox сверены;
- тип сообщения поддерживается;
- deadline получен из актуальных параметров;
- allowlist и pause проверены;
- L1 receipt сохранён;
- L2 inclusion и execution status проверены отдельно;
- комиссии и возможный reorg учтены.
Материал подготовлен редакцией сайта и проверен 29 октября 2026 года. Условия бирж, кошельков и блокчейн-сетей могут меняться. Перед операцией сверяйте данные в интерфейсе выбранного сервиса.