Короткий ответ: секвенсор принимает, упорядочивает и быстро подтверждает операции L2. При его остановке новые транзакции могут не попадать в блоки, RPC и обозреватели – отставать, а уже подписанные операции – оставаться неизвестными части сети. Средства не исчезают автоматически, но быстрый путь временно нарушается.
Секвенсор и RPC – не одно и то же
RPC принимает запросы кошелька и передаёт данные сети. Секвенсор определяет порядок транзакций и строит блоки L2. Если сломался один RPC-провайдер, другой может продолжать показывать свежие блоки и принимать операции. При реальной остановке секвенсора высота L2 перестаёт расти у разных независимых источников.
Сначала сравните два обозревателя, официальную страницу состояния и несколько RPC. Если один интерфейс не загружается, а блоки продолжаются, это локальная проблема. Не повышайте комиссию и не повторяйте платёж до определения причины.
Проверьте правильный chain ID: одинаковый адрес в другой сети способен создать ложное впечатление, что транзакция пропала.
Официальная страница состояния сама может обновляться с задержкой. Фактическая высота блоков и время последнего блока дают независимую проверку. Сравнивайте отметки времени, а не только зелёный индикатор сервиса.
Что происходит с уже отправленной транзакцией
Подписанная операция может находиться только в кошельке, у RPC или в очереди секвенсора. Пока она не включена в блок, статус зависит от того, какой узел спрашивает обозреватель. Сохраните raw transaction или TxID, если кошелёк их показывает, но не публикуйте приватные данные.
После восстановления секвенсор может принять старую операцию, если nonce и комиссия остаются действительными. Поэтому новый перевод с новым nonce способен исполниться дополнительно. Для замены используйте тот же nonce только после проверки исходного статуса.
Если транзакция уже включена в блок L2, простой секвенсора не отменяет её автоматически. Степень закрепления зависит от публикации данных и состояния Ethereum. Это объясняет статья о подтверждении L2 и финальности.
Можно ли отправить операцию через Ethereum
Некоторые rollup предусматривают принудительное включение сообщения или альтернативный путь через контракт L1. Его детали, задержки и стоимость зависят от протокола. Это аварийный механизм, а не универсальная кнопка во всех кошельках.
Вызов в Ethereum оплачивается ETH и требует точного контракта и формата данных. Не следуйте инструкции из случайного чата. Ошибка может привести к потере комиссии или отправке средств чужому контракту.
Для обычного пользователя безопаснее дождаться официального сообщения сети, если нет срочной необходимости и подтверждённых инструкций. Самостоятельное взаимодействие с аварийными функциями требует понимания L1-контракта.
Даже при наличии force inclusion результат может появиться не мгновенно. Протокол способен предусматривать задержку, чтобы обычный секвенсор успел обработать сообщение. Не создавайте несколько принудительных заявок на один экономический платёж.
Что происходит с мостами и выводами
Новый вывод нельзя инициировать без работающего пути включения L2-транзакции. Уже начатый вывод может продолжать стадии в Ethereum, если нужное состояние было опубликовано до остановки. Проверяйте этап, а не общий статус сайта.
Канонический и сторонний мосты реагируют по-разному. Сторонний сервис способен остановить выдачу ликвидности отдельно от L2. Разницу маршрутов раскрывает материал о каноническом и стороннем мосте.
Проверьте обе стороны моста. Ethereum может работать нормально, пока исходная L2 не производит блоки, или наоборот интерфейс моста может быть недоступен при исправных контрактах. Состояние сайта не равно состоянию средств.
Как обращаться с nonce после восстановления
Сверьте последнюю подтверждённую операцию адреса и первый ожидаемый номер. Если старая транзакция появилась в блоке, новый повтор не нужен. Если она не известна сети, кошелёк может повторно транслировать тот же подписанный payload. Для изменения комиссии создаётся конкурент с тем же nonce, а не новый платёж.
Несколько кошельков, подключённых к разным RPC, могут показывать разные очереди. Выберите один источник актуального состояния и не подписывайте параллельные замены в разных приложениях.
Практический алгоритм во время сбоя
- Не создавайте повторный платёж и сохраните все публичные параметры.
- Сравните высоту последнего блока в нескольких источниках.
- Проверьте официальное сообщение о состоянии секвенсора и RPC.
- Найдите TxID и nonce в нескольких обозревателях L2.
- Если операция подтверждена, дождитесь синхронизации индекса.
- Если не включена, решайте вопрос замены только после восстановления доступа.
- Используйте аварийный путь L1 лишь по актуальной официальной инструкции.
Если кошелёк выдаёт ошибку симуляции, сначала исключите сбой RPC. Отдельная инструкция объясняет, почему не удаётся оценить gas.
Когда статус кошелька устарел
После восстановления индексатор может догонять блоки медленнее сети. Обновите данные через другой RPC и проверьте receipt напрямую. Если операция имеет Success и устойчивый номер блока, не отправляйте её снова из-за надписи Pending в одном приложении.
При очереди из нескольких операций ищите наименьший nonce. Принцип описан в материале про разрыв nonce.
Что сообщать поддержке
Передайте сеть, публичный адрес, TxID, nonce, время, используемый RPC и последнюю видимую высоту блока. Seed-фраза, приватный ключ, пароль и 2FA не требуются. Поддержка не должна просить подпись «для перезапуска секвенсора».
Можно приложить точный текст RPC-ошибки и время ответа. Не публикуйте URL с персональным API-ключом провайдера – для диагностики достаточно его названия и метода запроса.
Итог
При сбое секвенсора отделите остановку производства блоков от ошибки одного RPC. Не дублируйте платёж, пока его судьба не ясна. Уже опубликованное состояние и этапы L1 могут продолжать жить отдельно, а аварийные функции следует использовать только по проверенным правилам конкретной L2.
