---
title: "Аварийный выход из Rollup"
description: "Руководство по аварийным выходам из Rollup: какие механизмы скрываются за термином, что они гарантируют, от чего зависят и как проверить путь выхода."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Аварийный выход из Rollup
> Материал предназначен только для обучения и не является финансовой рекомендацией или советом по безопасности. Механизмы выхода, задержки, комиссии, полномочия контрактов и допущения о доступности данных различаются между L2 и могут меняться после обновлений.
## Краткий ответ
Аварийный выход из Rollup — это резервный путь протокола, предназначенный для сохранения возможности пользователя выйти или провести транзакцию, когда оператор L2, секвенсор или обычный интерфейс не работает либо применяет цензуру. Термин не стандартизован. В зависимости от архитектуры это может быть принудительное включение через L1, запрос на принудительный вывод или режим выхода, который замораживает обновления состояния и позволяет выводить средства с доказательствами. Эти механизмы дают разные гарантии и не взаимозаменяемы.
Аварийный выход — более сильный резервный путь на случай остановки обычных обновлений состояния. Он может заморозить приложение и позволить пользователям доказать баланс относительно зафиксированного корня состояния. Ни один механизм не обещает мгновенный выход, определённую стоимость актива или защиту от ошибок контрактов и полномочий управления. Реальная гарантия определяется развёрнутым кодом, текущей конфигурацией, доступными данными состояния и способностью пользователя сформировать и отправить необходимые транзакции или доказательства.
## Как это работает
- **Определите примитив.** Принудительное включение, вывод и режим выхода решают разные задачи. Включение обходит цензурирующий или неработающий секвенсор. Запрос на вывод обязывает протокол или оператора обработать выход либо доказать его недействительность. Режим выхода обычно служит последней мерой: обычные обновления прекращаются, а вывод выполняется с доказательствами состояния.
- **Войдите через L1.** Пользователь отправляет транзакцию в указанный документацией inbox, портал или расчётный контракт L1. В OP Stack депозиты L1 выводятся в блоки L2 в пределах окна секвенирования. В Arbitrum Nitro сообщение попадает в Delayed Inbox и после настроенной задержки может быть принудительно включено в основной inbox, если секвенсор его не включил.
- **Дождитесь обработки.** Подтверждение L1 — лишь первая контрольная точка. Запросу может понадобиться войти в каноническую цепь L2, успешно исполниться, появиться в доказанном или подтверждённом состоянии, пройти период оспаривания или ожидания и финализироваться на L1. Принудительная транзакция тоже может откатиться из-за неверного nonce, нехватки Gas, ошибочной calldata, ограничений токена или изменения состояния L2.
- **Выполните условия выхода.** StarkEx Spot показывает настоящий принудительный вывод и аварийный выход. Пользователь отправляет `fullWithdrawalRequest`; приложение должно выполнить запрос или доказать его недействительность. Если после `FREEZE_GRACE_PERIOD` он остаётся в ожидании, можно запросить заморозку. Для выхода нужны Merkle-путь к замороженному корню хранилища, проверка доказательства, вызов `escape` и обычный ончейн-вызов `withdraw`.
- **Проверьте доступность данных.** Корень состояния — обязательство, а не сами балансы или Merkle-пути. Если данные для восстановления состояния опубликованы на L1, независимая сторона в принципе может построить доказательство выхода. В Validium и других моделях с офчейн-данными пользователь может зависеть от комитета или оператора, публикующего данные. Корректность доказательства и доступность данных — разные гарантии.
- **Проверьте управление и инструменты.** Изучите права паузы, заморозки, обновления и управления; точные адреса и proxy-реализации; поддерживаемые активы; нужные ключи; Gas L1 и L2; ПО для доказательств; наличие независимого интерфейса. Правильный на бумаге механизм может быть непрактичным без данных, инструментов или достаточных средств на L1.
## Пример
Предположим, секвенсор и официальный интерфейс Rollup недоступны, но L1 продолжает финализацию. Сначала пользователь сверяет chain ID и канонические контракты L1 с официальной документацией. Если есть только принудительное включение, он отправляет транзакцию из L1 в L2, вызывающую L2-функцию вывода канонического моста. Затем отдельно отслеживает отправку L1, принудительное включение, исполнение L2, фиксацию состояния, этап оспаривания или доказательства и финализацию L1. Успешная отправка L1 не доказывает успешность вызова вывода.
В системе типа StarkEx порядок иной: отправить документированный принудительный запрос, дождаться настроенного периода ожидания, проверить выполнение или доказанную недействительность и использовать заморозку с выходом лишь при выполнении условий контракта. Идентификатор хранилища, ключ и Merkle-путь должны соответствовать замороженному состоянию. Копировать процедуру Arbitrum или OP Stack неверно, даже если все они иногда называются «принудительным выводом».
До зависимости от любого пути протестируйте его небольшой суммой при исправной системе. Запишите адреса, сигнатуры функций, ожидаемые события, таймеры и хеши транзакций. Проверьте состояние через другой надёжный RPC или обозреватель. Никогда не вводите seed-фразу или закрытый ключ на сайте «экстренного вывода» и не отправляйте дополнительную плату за «разблокировку» службе поддержки или в личных сообщениях.
## Риски
- Есть принудительное включение, но нет прямой функции принудительного вывода.
- Запрос L1 подтверждён, однако вызов L2 откатился или ещё не исполнен.
- Период оспаривания, доказательства, ожидания или финализации задерживает средства.
- Данные состояния или Merkle-путь недоступны, особенно при офчейн-данных.
- Использованы неверные цепь, контракт, proxy, функция или идентификатор хранилища.
- Контракт выхода приостановлен, обновлён, ошибочно заморожен или содержит дефект.
- Управление, совет безопасности или иной привилегированный участник меняет путь.
- Актив не поддерживается, нестандартен, неликвиден или подчинён правилам маржи.
- Рост цены Gas L1 или отсутствие нативного Gas мешает отправке или финализации.
- Интерфейсы, RPC, индексаторы или инструменты доказательств недоступны.
- Поддельный интерфейс, реклама или поддержка крадут данные или средства.
- Стоимость может упасть во время задержки; возможность выхода не защищает цену.
## Распространённые заблуждения
- **У всех Rollup одинаковый аварийный выход.** Названия, механизмы и гарантии зависят от протокола; изучайте документы и контракты развёрнутой версии.
- **Принудительное включение сразу возвращает средства на L1.** Обычно оно гарантирует доступ к упорядочиванию или исполнению; у вывода через мост есть свой цикл.
- **Хеш транзакции L1 доказывает успешный выход.** Он доказывает лишь включение в L1; исполнение L2 и финализацию L1 проверяют отдельно.
- **Доказательство корректности гарантирует доступность данных выхода.** Корректность и доступность данных различны; офчейн-данные добавляют зависимости.
- **Аварийный путь не требует доверия, раз существует функция.** Применимость также зависит от прав, конфигурации, данных, ПО, Gas и ключей.
- **Аварийный выход устраняет финансовый риск.** Он решает проблему доступности или цензуры, но не цены, ликвидности, контрактов или компрометации ключей.
## Связанные темы
- [Канонический мост](/ru/crypto/canonical-bridge/)
- [Optimistic Rollup](/ru/crypto/optimistic-rollup/)
- [Принудительный вывод из L2](/ru/crypto/l2-forced-withdrawal/)
- [Секвенсор](/ru/crypto/sequencer/)
- [ZK Rollup](/ru/crypto/zk-rollup/)
## Источники
- [Обзор протокола OP Stack](https://specs.optimism.io/protocol/overview.html) - OP Stack Specification (дата обращения: 2026-08-21)
- [Arbitrum Nitro: Optimistic Rollup второго поколения](https://docs.arbitrum.io/nitro-whitepaper.pdf) - Offchain Labs (дата обращения: 2026-08-21)
- [Вывод и аварийный выход без одобрения приложения](https://docs.starkware.co/starkex/spot/withdrawing_and_escaping_without_app_approval.html) - StarkEx Documentation (дата обращения: 2026-08-21)
- [Доступность данных](https://docs.starkware.co/starkex/con_data_availability.html) - StarkEx Documentation (дата обращения: 2026-08-21)
Source: https://wiki.fcontext.com/ru/crypto/rollup-escape-hatch/index.mdx