Короткий ответ: канонический вывод из optimistic rollup не является одним мгновенным переводом. Пользователь инициирует сообщение в L2, оно включается в опубликованное состояние, затем проходит предусмотренный период оспаривания и после этого финализируется в Ethereum. Некоторые сети разделяют доказательство и claim на отдельные транзакции.
Почему нельзя сразу выдать монеты в Ethereum
Optimistic rollup предполагает корректность опубликованного результата, пока никто не доказал нарушение. Контракт моста не должен окончательно разблокировать актив в L1 до завершения процедуры, иначе ложное состояние могло бы привести к необратимому выводу.
Период оспаривания даёт участникам время проверить утверждение и начать предусмотренную протоколом проверку. Его длительность задаёт конкретная сеть. Не переносите срок из инструкции одного rollup на другой и не обещайте пользователю точное время без проверки текущих правил.
Быстрый статус Success у первой операции означает лишь успешную инициацию в L2. Средства назначения ещё могут быть недоступны, хотя исходный баланс уже уменьшился или актив заблокирован.
Этап 1: инициация вывода в L2
Пользователь вызывает контракт моста в исходной сети, указывает актив, сумму и получателя в Ethereum. Перед подписью проверьте направление: L2 → L1, контракт, получателя и комиссию. Ошибка в адресе назначения не исправляется последующим claim.
После подтверждения сохраните TxID L2. В receipt находятся сообщение и события, по которым инфраструктура отслеживает вывод. Если обозреватель не видит transfer на привычной вкладке, проверьте внутренние вызовы и события токенов.
Этап 2: публикация и доказательство
Блок L2 должен войти в пачку или утверждение, опубликованное в Ethereum. До этого мост L1 не имеет нужной опоры. Специализированный обозреватель обычно связывает пользовательское сообщение с L1-транзакцией публикации.
В некоторых реализациях пользователь или relayer отправляет отдельную транзакцию доказательства. Она сообщает контракту L1, что конкретный вывод входит в опубликованное состояние. Такой шаг оплачивается gas в Ethereum и имеет собственный TxID.
Не повторяйте инициацию, если интерфейс ждёт именно proof. Повторный вывод создаст новое сообщение и может заблокировать ещё одну сумму. Сопоставьте идентификатор сообщения и все хеши в официальном интерфейсе.
Этап 3: ожидание и финальный claim
После нужного состояния начинается или продолжается период ожидания. Кнопка финализации становится доступна только когда контракт разрешает выполнить сообщение. Обновление страницы не сокращает срок, а сторонний «ускоритель» не может изменить правила канонического контракта.
Финальный claim является L1-транзакцией. На адресе, который её отправляет, нужен ETH для gas, если сеть не предусматривает relayer. После успеха проверьте внутреннее движение ETH или token transfer и конечный баланс получателя.
Если кнопка недоступна после ожидаемого периода, проверьте, был ли отправлен proof, относится ли подключённый аккаунт к операции и не финализировано ли сообщение другим relayer. Не подписывайте случайный approve: обычному получению нативного ETH он не нужен.
Откуда берутся несколько TxID
Инициация живёт в L2, публикация, proof и claim – в Ethereum. Это разные транзакции в разных цепочках. Один хеш не обязан открываться во всех обозревателях. Принцип подробнее объясняет статья, почему у моста бывает два TxID.
Записывайте каждый хеш вместе с сетью и назначением. Фраза «транзакция подтверждена» без указания этапа недостаточна: подтверждён proof, но не claim, либо только инициация.
Некоторые интерфейсы выполняют отдельный этап автоматически через relayer, другие ждут действия пользователя. До начала вывода проверьте, кто отправляет финальную транзакцию и откуда оплачивается gas. Иначе средства могут надолго остаться готовыми к claim без фактической ошибки протокола.
Почему быстрый мост работает иначе
Сторонний сервис может выдать пользователю свою ликвидность в Ethereum почти сразу, а канонический вывод завершить позже самостоятельно. Это обмен требований и ликвидности, а не сокращение challenge period протокола.
За скорость добавляются комиссия и риски посредника, пула, валидаторов или отдельного контракта. Перед выбором сравните маршруты по статье о каноническом и стороннем мосте. Не судите только по обещанному времени.
Практический чек-лист
- Проверьте обе сети, актив, сумму и адрес получателя.
- Сохраните TxID инициации L2 и идентификатор сообщения.
- Дождитесь включения блока в опубликованную пачку.
- Выполните proof только через проверенный контракт, если он нужен.
- Проверьте начало и окончание периода оспаривания.
- Оставьте ETH на L1-комиссию и выполните финализацию.
- Сверьте баланс и события, а не только уведомление интерфейса.
Степень завершённости исходного блока помогает оценить материал про подтверждение L2 и финальность Ethereum.
Что можно передать поддержке
Сообщите L2, публичные адреса, актив, сумму, все TxID, идентификатор сообщения и текущий этап. Seed-фраза, приватный ключ, пароль и 2FA не нужны. Сотрудник не должен просить подпись для «ручной разблокировки», если вы не видите точный контракт и метод.
Снимок статуса делайте так, чтобы были видны сеть и этап, но скрывайте лишние персональные данные. Публичной информации достаточно для проверки записи в контрактах.
Итог
Многоэтапный вывод защищает канонический мост от неподтверждённого состояния optimistic rollup. Разделяйте инициацию, публикацию, proof, ожидание и claim. Не создавайте новый вывод из-за того, что первый TxID уже успешен, а средства в Ethereum ещё не появились.
