Перейти к содержанию
Financial Context Wiki

Что делать при остановке секвенсора L2

Практический план действий при остановке секвенсора L2: проверить сбой, не дублировать транзакции, уточнить резервный путь роллапа через L1 и учесть риски восстановления и ликвидации.

Обновлено

Только для образовательных целей; не является инвестиционным советом или рекомендацией. Инвестиции могут привести к убыткам.

Краткий ответ

Рассматривайте остановку секвенсора как потерю обычного доступа к L2, а не как доказательство отказа роллапа или утраты активов. Прекратите срочные действия, проверьте инцидент на официальной странице состояния сети и по независимым данным RPC или обозревателя, а до подписи выясните точный резервный путь этого роллапа через L1.

  1. Запишите сеть, адрес кошелька, хеши ожидающих транзакций, последний замеченный блок и время сбоя.
  2. Не отправляйте транзакцию повторно и не повышайте комиссию, пока ее статус неизвестен.
  3. Проверьте, движется ли unsafe head при остановившемся safe или finalized head; это может означать сбой публикации пакетов, а не полную остановку.
  4. Используйте путь принудительной транзакции или вывода через L1 только по официальной документации и с проверенными адресами контрактов.
  5. После восстановления дождитесь нормализации очереди, состояния оракула, моста и периода ожидания приложения, прежде чем повышать плечо или считать транзакцию окончательной.

Как это работает

Обычно секвенсор принимает, упорядочивает и быстро подтверждает транзакции L2, а затем публикует в слое доступности данных информацию, необходимую для построения сети. Остановка может блокировать обычную отправку через RPC. При отдельном сбое публикации секвенсор может продолжать создавать unsafe блоки, тогда как публикация в L1 и головы safe и finalized останавливаются. Риски реорганизации и восстановления в этих случаях различны.

Резервный путь зависит от реализации. В сетях OP Stack пользователь может отправить транзакцию L2 через проверенный OptimismPortal сети в L1; стандартное окно секвенирования составляет 12 часов, но может различаться. Arbitrum Nitro использует Delayed Inbox в L1, а опубликованная архитектура описывает принудительное включение после порога в 24 часа. Эти механизмы обеспечивают последующее включение, а не мгновенный универсальный выход, и по-прежнему требуют Gas в L1 и правильных контрактов конкретной сети.

Приложениям нужны собственные меры защиты. Канал состояния секвенсора может сообщить об остановке, но он отличается от ценового канала. Протоколы кредитования и деривативов могут приостановить чувствительные операции и ввести период ожидания после восстановления, чтобы накопившиеся обновления оракула и транзакции пользователей не привели сразу к несправедливым ликвидациям.

Пример

Заемщик держит ETH в залоге в кредитном протоколе L2. Секвенсор недоступен 2 часа, пока ETH падает на 15%, поэтому заемщик не может добавить залог через обычный RPC. Протокол выявляет сбой, приостанавливает ликвидации и сохраняет паузу в течение настроенного периода в 1 час после сообщения канала состояния о восстановлении.

Заемщик записывает хеш ожидающей транзакции, проверяет официальное сообщение и safe head роллапа и не доверяет сообщению поддержки со ссылкой на «разморозку». Если действие по-прежнему нужно, он следует официальному пути L1 и проверяет адрес portal или inbox. После восстановления он ждет отражения принудительной транзакции, цены и здоровья счета в safe блоке, прежде чем полагаться на результат.

Риски

  • Ликвидации при восстановлении: накопившиеся транзакции и цены могут обрабатываться почти одновременно; без периода ожидания пользователи, не способные действовать во время сбоя, могут быть немедленно ликвидированы.
  • Реорганизация unsafe состояния: RPC может показывать недавние блоки, еще не опубликованные в L1; при истечении окна публикации они могут быть реорганизованы.
  • Устаревшие или несовпадающие сигналы: обновляющаяся цена не доказывает возможность совершать транзакции, а канал состояния не доказывает актуальность цены.
  • Риск выполнения по принудительному пути: прямые вызовы L1 сложнее и дороже; неверные сеть, контракт, calldata, nonce или лимит Gas могут вызвать сбой или блокировку средств.
  • Задержки зависимых систем: мосты, биржи, keeper, индексаторы и интерфейсы могут восстанавливаться с разной скоростью даже после запуска секвенсора.

Распространенные заблуждения

  • «Секвенсор остановлен, значит активы исчезли». Состояние роллапа, обеспеченное L1, может оставаться целым, даже если обычный доступ недоступен.
  • «У всех роллапов одинаковая задержка принудительного включения». Окна, контракты и доступные действия зависят от реализации и конфигурации сети.
  • «Принудительная транзакция выполняется сразу». Отправка в L1 создает путь к последующему включению, но не убирает задержки секвенирования, доказательства или вывода.
  • «После возобновления блоков риск ликвидации исчезает». Очереди, обновления оракула и keeper могут сделать восстановление самым рискованным этапом.
  • «Ссылка на статус от поддержки безопасна». Независимо проверьте домен и контракт; никогда не раскрывайте сид-фразу или закрытый ключ.

Связанные темы

Источники

Навигация

Поиск по вики...