Можно ли вывести средства из Base или Arbitrum при отказе секвенсора?

Роллап может сохранить маршрут Ethereum открытым для пользователей, чьи транзакции застряли на секвенсоре. Этот маршрут обеспечивает включение транзакций. Возврат средств в Ethereum также зависит от того, может ли вывод из роллапа быть доказан и завершён по правилам моста.

Рассмотрим двух пользователей, владеющих ETH: один на Base, другой на Arbitrum One. Оба используют официальный мост, но пытаются выйти в разные моменты сбоя. Один вывод уже зафиксирован в записях роллапа. Другому ещё нужно добиться принятия транзакции.

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

Вывод состоит более чем из одного шага

В обычном режиме работы пользователь начинает с отправки транзакции вывода в роллапе. Секвенсор упорядочивает её вместе с другими транзакциями. Затем вывод через мост может быть установлен в Ethereum, как только соответствующее состояние роллапа станет доступным и будут выполнены применимые требования к доказательствам и ожиданию.

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

Маршрут в обход секвенсора

Документация Arbitrum о принудительных транзакциях описывает маршрут через его Delayed Inbox в Ethereum. Транзакция может ожидать там, прежде чем станет доступной для принудительного включения. Этот период отделён от времени, необходимого для завершения вывода в Ethereum.

Спецификация деривации Base описывает депозиты, производные от Ethereum, включая маршрут протокола для принудительного включения. Полезное сравнение заключается в том, может ли пользователь инициировать необходимое действие через Ethereum, сколько времени протоколу может потребоваться для его включения и что ещё должно произойти после включения.

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

Экстренное обновление проверяет иную защиту

Сбой поднимает вопрос о том, может ли транзакция попасть в роллап. Обновление поднимает вопрос о том, кто может изменить контракты, определяющие, будет ли вывод исполнен. Маршрут принудительной транзакции сам по себе не сохраняет существующие правила до тех пор, пока пользователь не сможет завершить вывод.

ETHBEAT перечисляет Base и Arbitrum One как Stage 1. В его оценке не показано окно выхода для Base и различаются обычные и экстренные обновления для Arbitrum One. Обычный путь Arbitrum указывает 10-дневное окно, тогда как экстренный путь такого окна не имеет.

Именно из-за этой разницы рейтинг Stage 1 сам по себе не может ответить на вопрос, сколько времени потребуется пользователю, чтобы вывести средства. Период уведомления необходимо рассматривать вместе со временем, необходимым для инициирования, подтверждения и завершения вывода. Соответствующий период — это время, оставшееся после учёта шагов, которые пользователю необходимо выполнить.

Мост третьей стороны добавляет свои условия

Быстрый мост может выплатить пользователю средства из ликвидности, которая уже есть у него в Ethereum, а свою позицию урегулировать позже. Это может сделать видимый вывод быстрее в обычном режиме работы. Это также вводит провайдера, чья ликвидность и операционная политика имеют значение, когда rollup находится под нагрузкой.

Актив также имеет значение. Баланс, выпущенный через мост третьей стороны, может зависеть от контрактов этого моста, даже если он хранится на Base или Arbitrum. Оценка официального механизма выхода rollup сама по себе не может установить, что внешний эмитент выкупит.

Справедливое сравнение предполагало бы проведение одного и того же типа актива через оба официальных моста с фиксацией первого включения, подтверждения и этапов завершения. Затем оно сравнило бы, что изменится, если секвенсор остановится, и что может сделать экстренное обновление до завершения любого из выводов.

Начните с одинакового вывода в обеих сетях

Возьмите пользователя, который держит нативный ETH в каждой сети и хочет вернуть ETH в Ethereum. Использование одного и того же актива упрощает сравнение, поскольку позволяет избежать отдельных правил выкупа, которые могут применяться к обёрнутым токенам. Официальному мосту по-прежнему нужны доказательства того, что вывод был инициирован и что состояние, содержащее его, было принято в соответствии с правилами rollup.

В обычном режиме работы пользователь отправляет инструкцию в rollup. Её включение создаёт запись, которую система вывода сможет позже распознать. Пользователь или интерфейс, действующий от его имени, может затем выполнить необходимые шаги в Ethereum. Средства становятся доступными в Ethereum после того, как соответствующий контракт моста выполнит вывод.

Кошелёк может отображать несколько видов прогресса. Он может показывать, что секвенсор принял транзакцию, что пакет достиг Ethereum или что вывод готов к следующему шагу. Эти метки описывают разные события. Интерфейс, который показывает транзакцию как подтверждённую, всё ещё может описывать её статус в rollup.

Вывод, начатый до сбоя, также отличается от вывода, который пользователь ещё не инициировал. Если транзакция и состояние, необходимые для её поддержки, уже достигли Ethereum, оставшаяся работа может выполняться там. Если единственным доказательством является недавний ответ от секвенсора, пользователю всё ещё нужны соответствующие данные и состояние, чтобы пройти через остальную часть системы.

Это различие помогает объяснить, почему первый полезный вопрос во время сбоя — это где остановился вывод. Отсутствующая транзакция rollup требует маршрута для включения. Вывод, уже записанный в rollup, может ожидать этапа подтверждения или завершения. Следующее действие зависит от того, какого из этих этапов достигла сеть.

Что меняется, когда секвенсор останавливается

Секвенсор обычно даёт пользователю быстрый маршрут для упорядочивания транзакции. Если сервис перестаёт отвечать, отправленная транзакция может не появиться, даже если Ethereum продолжает работать. Маршрут через Ethereum даёт пользователям способ поместить сообщение во входные данные rollup, не дожидаясь возврата его обычной конечной точки.

В Arbitrum One Ethereum записывает сообщения в Delayed Inbox. Секвенсор может включить их в обычном порядке. Если сообщение остаётся там дольше применимого времени ожидания, маршрут принудительного включения может сделать его частью последовательности. Транзакция Ethereum, записывающая сообщение, и транзакция rollup, исполняющая его, остаются отдельными наблюдениями.

В Base депозиты, записанные в Ethereum, становятся входными данными для правил деривации rollup. Термин «депозит» может вводить в заблуждение в этом контексте, поскольку он также относится к типу сообщения, через которое транзакция Ethereum может инициировать действие в rollup. Предполагаемая пользователем операция rollup всё ещё должна успешно выполниться после включения.

Страницы проектов ETHBEAT описывают задержку в условиях, которые они моделируют. Оценка применяется к резервному шагу и может различаться между двумя сетями. Она не превращает мост rollup-to-Ethereum в немедленный вывод. Окончательная выплата по-прежнему зависит от того, примет ли мост результирующее состояние и завершит ли свои собственные шаги.

Пользователю также нужны средства для отправки транзакции Ethereum. Тот, чей весь баланс находится в rollup, может нуждаться в доступе к ETH в Ethereum для резервного варианта. Приложение, которое обрабатывает это для пользователей в обычных условиях, может столкнуться с тем же практическим ограничением, если оно полагается на отказавшую конечную точку или не предоставляет маршрут через Ethereum.

Получатель также должен отличать неудавшийся запрос от успешной отправки в сеть, которая ещё не вступила в силу. Хеш транзакции из Ethereum подтверждает, что резервное сообщение было отправлено, если его квитанция это подтверждает. Он не устанавливает результат последующего выполнения в роллапе.

Когда сеть продолжает производить блоки, но выводы застревают

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

Различие проистекает из разных выполняемых задач. Секвенсор упорядочивает транзакции. Доступность данных позволяет другим сторонам восстановить, что было упорядочено. Системы предложения и доказательств устанавливают, какое результирующее состояние контракты Ethereum должны признать. Служба может выполнять одну из этих задач, пока другая ожидает.

Для наблюдателя обозреватель блоков, всё ещё показывающий активность, поэтому является неполной проверкой. Наблюдатель может сравнить недавнее включение транзакций в роллапе с записями Ethereum о состоянии или заявках, от которых зависят выводы. Разрыв между ними помогает определить, находится ли узкое место раньше или позже.

ETHBEAT отличает отказ секвенсора от отказа предлагающего, потому что резервный вариант для одного не обязательно решает проблему другого. Его категории — это способ увидеть, какой участник может вмешаться, когда обычный оператор отсутствует. Их следует читать с учётом условий и задержки, описанных для каждого проекта.

Тот же принцип применяется к сообщениям о деградации обслуживания. Фронтенд может быть недоступен, пока контракты остаются вызываемыми. Обозреватель может отставать, пока цепочка продвигается. Интерфейс моста может отключать отправку во время инцидента, даже если другой интерфейс всё ещё может достичь контрактов. Каждый случай следует проверять на том уровне, где он возникает.

Crypto.news сообщил, что Base пережил 33-минутный сбой в августе 2025 года. Этот инцидент даёт повод спросить, какие действия пользователей были прерваны и какие альтернативы оставались доступными. Его длительность не устанавливает, как будущее событие, затрагивающее другой компонент, повлияет на выводы.

Ожидание после включения принадлежит мосту

Как только вывод находится в состоянии роллапа, он всё ещё должен пройти условия доказательства и финализации моста. Оптимистичные схемы дают участникам возможность оспорить неверное заявление. Задержка может быть намеренной частью этого процесса, а не признаком того, что секвенсор офлайн.

Отсчёт начинается с события, определённого мостом, которое не обязательно совпадает с моментом, когда пользователь впервые нажимает «вывести». Ожидание может зависеть от того, когда доступен соответствующий выход или заявление и был ли подано требуемое доказательство. Пользователь может потратить время на ожидание до того, как период оспаривания, указанный в описании моста, начнёт иметь значение.

Таким образом, обратный отсчёт в кошельке может описывать оценку, а не безусловную дату платежа. Он может зависеть от продолжения нормальной публикации и активности доказательств. Если состояние оспаривается, время до финализации может измениться, даже если сама инструкция вывода уже отображается в роллапе.

Система доказательств Arbitrum и схема доказательств Base имеют разные детали реализации. Практическое сравнение для пользователя — это кто может подать заявление, кто может его оспорить и что произойдёт, если участник, который обычно подаёт следующее заявление, остановится. Одно и то же слово «вывод» охватывает разные последовательности в этих системах.

Задержка также влияет на сравнения со сторонними мостами. Служба, которая может немедленно заплатить пользователю в Ethereum, использует свою собственную ликвидность или отдельную сеть участников. Быстрый платёж может завершиться до того, как официальный вывод за ним станет иметь право на расчёт.

Затем пользователь полагается на способность и готовность третьей стороны осуществить платёж. Если ликвидность исчерпана или провайдер перестаёт принимать запросы, скорость, указанная для обычных сделок, может больше не применяться. Защитные механизмы выхода базового роллапа и условия выплаты коммерческой службы остаются различными.

Вопрос об обновлении касается того, какие правила будут действовать завтра

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

В рамках обычного процесса управления объявленное обновление может быть обязано пройти через задержку, прежде чем вступить в силу. В течение этого периода пользователи могут оценить предложение и начать выходить, если мост остаётся открытым. Полезное окно выхода — это то, что остаётся после учёта обычных шагов вывода средств.

В рамках экстренного пути назначенные подписанты иногда могут действовать без обычной задержки. Это может помочь быстро отреагировать на инцидент безопасности. Это также даёт пользователям иную гарантию, чем та, которую они видят, когда управление идёт обычным путём.

В оценке Arbitrum One указано десять дней для обычного пути и отсутствие окна выхода для экстренного обновления. В оценке Base окно выхода не указано. Итоговый рейтинг стадии может быть одинаковым, тогда как эти полномочия на практике различаются.

Пауза — это ещё одно действие, которое следует отличать от обновления. Пауза может остановить конкретную операцию в рамках существующих правил контракта. Обновление может заменить или изменить эти правила. Подписант и порог, необходимые для паузы, могут отличаться от подписанта и порога для новой реализации.

Crypto.news освещал конкретный пример экстренных полномочий, когда Совет безопасности Arbitrum переместил средства, связанные со взломом Binance. Этот случай касался идентифицированных средств и временного изменения контракта. Его relevance здесь в том, что экстренные полномочия могут быть реализованы на практике и могут быть отделены от последующего процесса, определяющего, куда направляются средства.

Как читать Stage 1, не принимая его за гарантию выхода

Классификации стадий объединяют несколько измерений роллапа. Они указывают, насколько система отошла от зависимости от операторов или советов в соответствии с критериями框架. Метка стадии не может дать ответ для каждого режима отказа, поскольку каждая защита решает不同的 задачу.

Для пользователя важны детали — это условия, применимые к его транзакции. Резервный вариант секвенсора имеет значение, если транзакция не может быть включена. Возможность предлагать состояние имеет значение, если обычный предлагающий роллапа останавливается. Задержка обновления имеет значение, если кто-то может изменить то, что будет делать мост, пока пользователь ждёт.

Доступность данных относится к тому же сравнению. Если данные, необходимые для реконструкции роллапа, доступны в Ethereum, у другого участника есть основа для следования за цепочкой. Само существование данных не выполняет доказательство и не отправляет транзакцию Ethereum от имени пользователя.

Base и Arbitrum One могут оба предлагать маршрут через Ethereum при проблеме с секвенсором, сохраняя при этом разные разрешения в отношении обновлений. Практическая оценка фиксирует оба, а не усредняет их в единый балл. Пользователю, пытающемуся выйти, нужен самый слабый соответствующий шаг для события, с которым он сталкивается.

Допущения также различаются в зависимости от токена. Нативный ETH может следовать собственным правилам официального моста. Токен, прибывший через сторонний контракт, может добавлять элементы управления эмитента или моста. Два кошелька на одном и том же роллапе могут столкнуться с разными условиями погашения, даже если их интерфейсы показывают оба баланса в одинаковом долларовом выражении.

Инцидент с мостом Ankr представляет отдельный пример того, как логика моста может определять, действителен ли вывод средств. Он касался другой системы. Его relevance — это различие между активностью в цепочке и правилами, которые мост использует для принятия сообщений и высвобождения активов.

Что может установить сравнение выхода

Сравните двух пользователей, которые инициируют обычные выводы средств до сбоя секвенсора. Если каждый вывод уже является частью состояния, доступного мосту в Ethereum, оставшиеся шаги зависят от процесса доказательства и финализации. Сбой может оказать мало прямого влияния на уже созревший вывод, если исполнение Ethereum остаётся доступным.

Теперь переместите сбой раньше. Ни у одного пользователя транзакция вывода не включена. Обоим нужно достичь маршрута роллапа на стороне Ethereum или ждать нормального обслуживания. Время до включения может различаться, а собственное ожидание моста наступает после.

Наконец, представьте экстренное контрактное действие, пока выводы средств находятся в ожидании. Соответствующие доказательства становятся основанием для действия, точные затронутые контракты и то, какие шаги допускает новая конфигурация. Ранее включённая транзакция может всё ещё требовать, чтобы мост распознал её по правилам, действовавшим на момент, когда пользователь пытается завершить операцию.

Эти случаи показывают, почему справедливое сравнение начинается с одного и того же состояния. Пользователя, который отправил сообщение в Ethereum, но ещё не увидел выполнения rollup, не следует напрямую сравнивать с тем, чьё доказательство моста уже было принято. Отсчёт начинается с разных событий.

Crypto.news сообщал о усилиях по обеспечению совместной работы rollup-ов Ethereum. Более гладкий интерфейс может скрывать несколько шагов в обычной транзакции. В условиях стресса пользователю полезно знать, какие части операции выполняются в какой цепочке и кто отвечает за каждую часть.

Освещение Crypto.news предложения о восстановлении Arbitrum, связанного с Binance, также показывает, почему действие управления следует читать вместе с транзакцией, которую оно санкционирует. Предложение описывает предполагаемый результат. Записи Ethereum и rollup показывают, когда и где оно было выполнено.

Маршрут выхода полезен лишь в той мере, в какой держатель может использовать его из своей текущей позиции. Наиболее ясная запись определяет актив, цепочку, в которой он находится, уже завершённую транзакцию и сторону или контракт, контролирующий следующий шаг. Эта запись сообщает пользователю, принадлежит ли оставшееся ожидание секвенсору, мосту или органу, способному изменить любой из них.

Почему более быстрое доказательство не обязательно сокращает каждый выход

Обновление Azul от Base ввело новые варианты доказательств. Crypto.news сообщал о потенциальном пути к однодневным выводам средств. Целевую возможность или возможность доказательства необходимо отличать от времени вывода, на которое конкретный пользователь может рассчитывать при активной конфигурации.

Доказательство может помочь установить состояние, от которого зависит вывод средств. Мост всё ещё может применять другие условия перед высвобождением средств. Последовательность также может различаться в зависимости от того, какой путь доказательства использует сеть и что происходит, когда этот путь недоступен.

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

Вывод средств из Ethereum также требует транзакции, которая может быть отправлена и выполнена в Ethereum. Сторонний сайт может предложить выполнить этот шаг, но его способность принять запрос отделена от того, может ли официальный контракт обработать его. Пользователю, который видит, что действие стало доступным, всё ещё нужен кошелёк или сервис, способный отправить его.

Это различие становится важным, если пользователь держит активы от имени приложения или клиента. Казначейство может требовать нескольких одобрений перед любым действием в Ethereum. Обычному пользователю может потребоваться подключение кошелька и газ. Доступное время выхода протокола и время, необходимое человеку для действия, могут различаться.

Что публичная запись может показать после сбоя

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

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

Освещение Crypto.news экстренного вмешательства в Arbitrum иллюстрирует необходимость отделять действие, выполненное советом, от процесса управления, который за ним следует. Наличие записи в Ethereum может установить, что контрактное действие произошло. Это не устраняет необходимости прочитать, какой орган его выполнил и на что оно повлияло.

Прямой ответ на вопрос о выводе средств зависит от того, когда происходит сбой. До включения смотрите на резервный механизм Ethereum и связанную с ним задержку. После включения смотрите на требования к состоянию, доказательству и финализации. Во время экстренного изменения полномочия приостанавливать или изменять контракты становятся решающими, даже если другие системы работают.

У пользователя также может быть несколько выводов средств на разных этапах этой последовательности. Один может быть готов к завершению, пока другой всё ещё ждёт включения. Уведомление о сбое, дающее одно ожидаемое время восстановления, не может установить статус обоих.

Квитанция о выводе средств — это финальная проверка

Интерфейс моста может пометить вывод средств как готовый до того, как пользователь отправил транзакцию для его завершения. Квитанция транзакции Ethereum — это отдельная запись. Для нативного ETH получатель также может проверить, что перевод поступил на нужный адрес и что получатель может им воспользоваться.

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

Роллап и мост также могут восстанавливаться по разным графикам. Секвенсор может возобновить работу, пока более старые выводы средств всё ещё ожидают состояния или доказательства. Появление новых транзакций роллапа снова является свидетельством восстановления сервиса для упорядочивания, но пользователям, ожидающим получения ETH в Ethereum, всё ещё нужно проверять статус собственного завершения.

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

Для двух пользователей в сравнении итоговое доказательство одно и то же. Их выводы средств через официальный мост завершены, когда Ethereum фиксирует высвобождение ETH в пользу предполагаемого получателя. Всё, что было до этого, говорит им о том, какая часть маршрута работает и что ещё должно произойти.

На что обратить внимание

• Статус секвенсора: Уведомление о статусе и сводные записи транзакций могут показать, когда обычный порядок был остановлен и возобновлён.
• Входящие сообщения Ethereum: Успешный чек Ethereum может подтвердить, что резервное сообщение было отправлено и когда оно стало доступным для включения.
• Публикация состояния: Записи Ethereum могут показать, есть ли у моста требование или выходные данные, необходимые для обработки вывода.
• Экстренные действия: Авторизующие подписанты, затронутые контракты и время транзакции определяют, изменила ли пауза или обновление маршрут пользователя.
• Обеспечение актива: Эмитент токена и мост определяют, применяется ли официальное сравнение вывода к этому балансу.

Часто задаваемые вопросы