Статус proven означает запись доказательства вывода, а не исполненную выплату получателю. В подходящем процессе OP Stack с fault proofs для завершения также важны зрелость доказательства, допустимое состояние и финальность связанной dispute game, затем отдельное действие L1. Проверяйте условия конкретной цепочки и портала вместо одного отсчёта от первоначальной отправки L2.
Разделите три транзакции
В официальном описании вывода выделены инициирование на L2, доказательство на L1 и завершение на L1. У этапов разные задачи. Успех L2 устанавливает исходное действие, доказательство L1 подтверждает основание для последующего исполнения. Ни один из них по отдельности не означает выполненное целевое получение. Сохраните их идентификаторы раздельно.
| Запись или состояние | Что установлено | Что ещё требуется |
|---|---|---|
| Вывод инициирован на L2 | Есть исходное действие | Подходящее предложение состояния и доказательство |
| Доказательство подтверждено на L1 | Успешно подана proof-транзакция | Зрелость и пригодность связанной игры |
| Приложение показывает proven | Интерфейс распознал proof-состояние | Какая запись и условия портала использованы |
| Временное условие выполнено | Пройден один нужный порог | Остальная допустимость и финальная отправка |
| Финализация ожидает | Есть попытка L1 | Включение и фактическое исполнение |
| Финализация или relay отказали | Возникла определённая ошибка | Поддерживаемое продолжение данного случая |
| Целевое действие успешно | Можно проверить сетевой результат | Внутреннее зачисление, если получатель сервис |
Здесь рассматривается стандартный путь и применимый к нему fault-proof портал. У стороннего быстрого моста, вывода биржи и другой реализации OP Stack этапы могут отличаться. Запишите цепочку, приложение, хеш инициирования L2, хеш доказательства L1 и назначение. Одна подпись состояния без этих сведений не объясняет, какой именно перевод проверял интерфейс.
Проверьте два ожидания и результат игры
В спецификации Optimism Portal зрелость доказательства отделена от финальности dispute game. Возраст proof отсчитывается от соответствующей записи подачи. Связанная игра также должна удовлетворять требованиям допустимого утверждения. Доказательство против ещё идущей игры не подтверждает прохождение всех условий завершения.
Поздняя подача против уже разрешённой игры автоматически не отменяет собственное ожидание доказательства. Старое proof, наоборот, не делает неразрешённую или неподходящую игру пригодной. Важны настроенные параметры и текущее состояние портала. Нельзя копировать срок другой цепочки либо считать знакомую формулировку «семь дней» универсальным предельным временем выплаты. Сначала определите, к какому событию привязан срок.
Для учебного сравнения допустим, что один временной порог достигается в День 9, другой — в День 11. Нижняя временная граница тогда День 11 при соблюдении остальных условий. Это условные обозначения, а не параметры OP Mainnet и не обещанные даты. Пример показывает, почему один прошедший таймер не заменяет второй. В реальном случае нужны фактические записи и значения.
Доказательство может ссылаться на непригодную игру
Спецификация описывает требования к регистрации, поддерживаемому типу и допустимости игры, включая состояния, не позволяющие завершение. Поэтому существование proof отличается от его пригодности сейчас. Если игра отвергнута либо перестала подходить, дальнейшее ожидание не обязательно решает проблему. Поддерживаемому приложению может потребоваться выбрать и подать подходящее доказательство. Уточняйте основание, а не только возраст операции.
В спецификации интеграции моста объясняется переход от прежних допущений output oracle к проверке через dispute games. Старая инструкция способна использовать другие термины и поля. Установите реально применённый процесс до следования руководству. Скриншот прежней версии не подтверждает пригодность текущего proof и не объясняет современный отказ.
Не подавайте доказательство многократно только ради продвижения надписи. Новая подача может изменить соответствующую запись и её отсчёт. Следуйте диагностированному шагу официального интерфейса либо спросите поддержку о невыполненном условии. Это не простое обновление страницы. Новое инициирование на L2 вообще создаёт другой вывод, поэтому его нельзя считать безопасной кнопкой продолжения старого случая.
Готовность ещё требует завершающего действия
После выполнения условий выясните, действительно ли отправлена финализация. Подпись кошелька может ожидаться, опубликованная транзакция — находиться в очереди, исполнение — завершиться ошибкой. Сохраните отдельный хеш L1 и точный результат. Повышенная комиссия не делает молодое доказательство зрелым и не превращает недопустимую игру в пригодную. Сначала проверьте условие, затем стоимость выполнения.
После включения изучите исход вывода или передачи сообщения. Наличие внешней транзакции не описывает весь результат для получателя. Документация вывода разделяет поведение ошибок на уровнях вызовов. Отказ целевого действия и непрохождение условий портала — разные случаи. Не считайте любой сбой основанием снова отправлять ту же финализацию; используйте порядок для фактических моста и сообщения.
Если назначение принадлежит кастодиальной платформе, сетевая операция и внутреннее зачисление остаются самостоятельными вопросами. До обращения о балансе проверьте действительные актив и адрес. Квитанция с другим назначением не исправляется настройкой отображения кошелька. Сохраните исходные реквизиты, чтобы последующая переписка не подменила то, что первоначально ожидалось.
Одна надпись может скрывать три причины
Представим три вымышленные записи proven. У «Ясеня» игра подходит, но недавно поданное доказательство ещё молодо. У «Берёзы» время прошло, однако игра непригодна. У «Кедра» условия соблюдены, но финальная транзакция не отправлялась. Следующее действие поэтому различается: ожидание, проверка proof или завершающий шаг. Эти названия не относятся к настоящим инцидентам.
Полезное обращение называет подтверждённую ветку. Укажите время проверки, конкретный портал и нужные ссылки. Не публикуйте всю историю кошелька, когда достаточно нескольких публичных идентификаторов. Свяжите предложенное действие с этим выводом, чтобы новый исходный перевод не приняли за его продолжение. Если причина неизвестна, прямо отметьте, какого свидетельства пока нет.
- Определите стандартный маршрут, исходную сеть, цель и ожидаемый актив.
- Найдите инициирование L2 и реальную запись proof на L1.
- Отделите возраст доказательства от разрешения, допустимости и финальности игры.
- Сверьте состояние портала и следующий официальный шаг вместо одного таймера.
- При допустимости выясните, отправлена ли финализация и что дала эта попытка.
- Передайте непонятное условие поддержке с хешами, без секретов и дублирующего вывода.
Продуктовый контекст изложен в руководстве Standard Bridge. Разницу уровней помогают понять межсетевые мосты и обозреватели L2. Для обмена без регистрации действуют инструкции его маршрута: срок заказа нельзя выводить из отсчёта стандартного вывода OP.
Частые вопросы
Срок вывода Optimism считается только от отправки L2?
У применимого fault-proof процесса есть также время от proof и условия финальности игры. Проверяйте конкретную цепочку и портал вместо единого отсчёта для всех этапов.
Почему вывод Optimism остаётся proven после ожидания?
Доказательство может зависеть от неподходящей игры, а отдельная финализация может отсутствовать. Установите незавершённое условие до следующего действия.
Нужно создавать новый вывод Optimism, если нет finalized?
Новая исходная операция создаст другой перевод и не завершит предыдущий. Сначала проверьте proof и финальную попытку первоначального вывода.