Чи можна вивести кошти з 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 засвідчує, що резервне повідомлення було подано, якщо його квитанція це підтверджує. Він не засвідчує результат подальшого виконання на rollup.

Коли мережа продовжує виробляти блоки, але виведення коштів зупиняється

Мережа може обробляти транзакції, тоді як інша частина процесу виведення коштів затримується. Контрактам на Ethereum потрібен визнаний облік того, що сталося на rollup. Затримка в публікації або встановленні цього стану може змусити користувачів чекати після того, як секвенсор уже повернув успішний результат.

Ця відмінність походить від різних задіяних завдань. Секвенсор упорядковує транзакції. Доступність даних дозволяє іншим сторонам відтворити те, що було впорядковано. Системи пропозицій і доказів встановлюють, який результуючий стан контракти Ethereum повинні визнати. Сервіс може виконувати одне з цих завдань, тоді як інше очікує.

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

ETHBEAT відрізняє збій секвенсора від збою пропонера, оскільки резервний варіант для одного не обов'язково вирішує інший. Його категорії є способом побачити, який учасник може втрутитися, коли звичайний оператор відсутній. Їх слід читати з умовами та затримкою, описаними для кожного проєкту.

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

Crypto.news повідомив, що Base зазнав 33-хвилинного збою у серпні 2025 року. Цей інцидент дає привід запитати, які дії користувачів були перервані та які альтернативи залишалися доступними. Його тривалість не встановлює, як майбутня подія, що стосується іншого компонента, вплине на виведення коштів.

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

Щойно виведення коштів потрапляє до стану rollup, воно все ще має пройти умови доказу та фіналізації мосту. Оптимістичні дизайни дають учасникам можливість оскаржити неправильне твердження. Затримка може бути навмисною частиною цього процесу, а не ознакою того, що секвенсор офлайн.

Відлік часу починається від події, визначеної мостом, яка не обов'язково збігається з моментом, коли користувач уперше натискає кнопку виведення. Очікування може залежати від того, коли відповідний вихід або твердження стає доступним і чи було подано необхідний доказ. Користувач може витратити час на очікування, перш ніж період оскарження, що згадується в описі мосту, почне мати значення.

Таким чином, зворотний відлік у гаманці може описувати оцінку, а не безумовну дату платежу. Він може залежати від продовження нормальної діяльності з публікації та доказів. Якщо стан оспорюється, час до фіналізації може змінитися, навіть якщо сама інструкція про виведення коштів уже з'явилася на rollup.

Система доказів Arbitrum і дизайн доказів Base мають різні деталі реалізації. Практичне порівняння для користувача полягає в тому, хто може подати твердження, хто може його оскаржити та що станеться, якщо учасник, який зазвичай подає наступне твердження, зупиниться. Те саме слово «виведення» охоплює різні послідовності в цих системах.

Затримка також впливає на порівняння зі сторонніми мостами. Сервіс, який може негайно сплатити користувачеві на Ethereum, використовує власну ліквідність або окрему мережу учасників. Швидкий платіж може завершитися до того, як офіційне виведення коштів, що стоїть за ним, стане придатним для розрахунку.

Потім користувач покладається на здатність і готовність третьої сторони здійснити платіж. Якщо ліквідність вичерпана або постачальник припиняє приймати запити, швидкість, зазначена для звичайних операцій, може більше не застосовуватися. Захисні механізми виходу базового rollup і умови виплати комерційного сервісу залишаються різними.

Питання оновлення стосується того, які правила діятимуть завтра

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

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

У рамках аварійного шляху призначені підписанти іноді можуть діяти без звичайної затримки. Це може допомогти швидко реагувати на інцидент безпеки. Це також дає користувачам іншу гарантію, ніж ту, яку вони бачать, коли управління йде звичайним шляхом.

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

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

Crypto.news висвітлив конкретний приклад аварійних повноважень, коли Рада з безпеки Arbitrum перемістила кошти, пов'язані зі зломом Binance. Цей випадок стосувався ідентифікованих коштів і тимчасової зміни контракту. Його актуальність тут полягає в тому, що аварійні повноваження можуть застосовуватися на практиці й можуть бути відокремлені від подальшого процесу, який визначає, куди надходять кошти.

Як читати Stage 1, не сприймаючи його як гарантію виходу

Класифікації стадій групують кілька вимірів ролапу. Вони вказують, наскільки система відійшла від залежності від операторів або рад за критеріями фреймворку. Позначка стадії не може дати відповідь для кожного режиму відмови, оскільки кожен захист вирішує інше завдання.

Для користувача важливими деталями є умови, що застосовуються до його транзакції. Резервний шлях секвенсора має значення, якщо транзакцію не вдається включити. Можливість пропонувати стан має значення, якщо звичайний пропонер ролапу зупиняється. Затримка оновлення має значення, якщо хтось може змінити те, що робитиме міст, поки користувач чекає.

Доступність даних належить до того самого порівняння. Якщо дані, необхідні для реконструкції ролапу, доступні на Ethereum, інший учасник має основу для відстеження ланцюга. Існування даних саме по собі не виконує доказ і не подає транзакцію Ethereum від імені користувача.

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

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

Інцидент з мостом Ankr надає окремий приклад того, як логіка мосту може визначати, чи є виведення дійсним. Він стосувався іншої системи. Його актуальність полягає в розрізненні між активністю в ланцюзі та правилами, які міст використовує для прийняття повідомлень і вивільнення активів.

Що може встановити порівняння виходу

Порівняйте двох користувачів, які ініціюють звичайні виведення до збою секвенсора. Якщо кожне виведення вже є частиною стану, доступного мосту на Ethereum, решта кроків залежить від процесу доказу та фіналізації. Збій може мати мало прямого впливу на вже дозріле виведення, якщо виконання на Ethereum залишається доступним.

Тепер перемістіть збій раніше. Жоден користувач не має включеної транзакції виведення. Обидва повинні досягти маршруту ролапу на боці Ethereum або чекати на нормальне обслуговування. Час до включення може відрізнятися, а власне очікування мосту настає після цього.

Нарешті, уявіть екстрену контрактну дію, поки виведення коштів очікують на обробку. Відповідні докази стають підставою для цієї дії, а також визначають, які саме контракти порушено і які кроки дозволяє нова конфігурація. Раніше включена транзакція все ще може потребувати, щоб міст визнав її за правилами, чинними на момент, коли користувач намагається завершити операцію.

Ці випадки показують, чому справедливе порівняння починається з однакового стану. Користувача, який надіслав повідомлення до Ethereum, але ще не побачив виконання ролапу, не слід порівнювати безпосередньо з тим, чий доказ мосту вже було прийнято. Відлік часу починається з різних подій.

Crypto.news повідомляв про зусилля, спрямовані на те, щоб змусити ролапи Ethereum працювати разом. Зручніший інтерфейс може приховувати кілька кроків у звичайній транзакції. Під час стресу користувачеві корисно знати, які частини операції відбуваються в якому ланцюжку і хто відповідає за кожну частину.

Висвітлення Crypto.news пропозиції щодо відновлення Arbitrum, пов'язаної з Binance, також показує, чому дію управління слід читати разом із транзакцією, яку вона авторизує. Пропозиція описує передбачуваний результат. Записи Ethereum і ролапу показують, коли і де її було виконано.

Шлях виходу корисний лише тією мірою, якою власник може скористатися ним зі своєї поточної позиції. Найчіткіший запис ідентифікує актив, ланцюжок, у якому він перебуває, вже завершену транзакцію та сторону або контракт, що контролює наступний крок. Цей запис повідомляє користувачеві, чи належить решта очікування секвенсору, мосту чи органу, здатному змінити будь-що з них.

Чому швидший доказ не обов'язково скорочує кожен вихід

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

Доказ може допомогти встановити стан, від якого залежить виведення коштів. Міст все ще може застосовувати інші умови перед вивільненням коштів. Послідовність також може відрізнятися залежно від того, який шлях доказу використовує мережа і що відбувається, коли цей шлях недоступний.

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

Виведення з Ethereum також вимагає транзакції, яку можна подати та виконати в Ethereum. Сторонній сайт може запропонувати виконати цей крок, але його здатність прийняти запит відокремлена від того, чи може офіційний контракт його обробити. Користувачеві, який бачить, що дія стала доступною, все ще потрібен гаманець або сервіс, здатний її подати.

Ця різниця стає важливою, якщо користувач тримає активи від імені застосунку або клієнта. Казначейство може вимагати кількох схвалень перед будь-якою дією в Ethereum. Звичайному користувачеві може знадобитися підключення гаманця та газ. Доступний час виходу за протоколом і час, потрібний людині для дії, можуть відрізнятися.

Що публічний запис може показати після збою

Звіт про інцидент може починатися з останньої нормальної відповіді секвенсора та першої затриманої транзакції. Потім він може визначити, чи продовжували дані та стан надходити до Ethereum. Записи можуть допомогти пояснити, чому одні користувачі бачили переривання, тоді як інші все ще могли завершити раніші виведення коштів.

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

Висвітлення Crypto.news екстреного втручання в Arbitrum ілюструє необхідність відокремлювати дію, виконану радою, від процесу управління, що за нею слідує. Наявність запису в Ethereum може встановити, що контрактна дія відбулася. Це не усуває потреби прочитати, який орган її виконав і на що вона вплинула.

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

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

Квитанція про виведення — це остаточна перевірка

Інтерфейс мосту може позначити виведення як готове ще до того, як користувач надіслав транзакцію для його завершення. Квитанція транзакції Ethereum є окремим записом. Для нативного ETH одержувач також може перевірити, що переказ надійшов на призначену адресу і що одержувач може ним скористатися.

Ця різниця має значення, коли користувач повторює дію після збою. Дві спроби надіслати інструкцію можуть дати різні повідомлення або лише одну прийняту транзакцію, залежно від того, як були зроблені запити. Історія гаманця може допомогти користувачеві визначити, яке повідомлення визнає міст, перш ніж він спробує наступний крок.

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

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

Для двох користувачів у порівнянні остаточний доказ однаковий. Їхні офіційні виведення через міст завершені, коли Ethereum фіксує вивільнення ETH на призначеного одержувача. Усе до цього моменту вказує їм, яка частина маршруту працює і що ще має відбутися.

На що звернути увагу

• Статус секвенсора: Повідомлення про статус і зведені записи транзакцій можуть показати, коли звичайне впорядкування зупинилося та відновилося.
• Вхідна скринька Ethereum: Успішний квиток Ethereum може підтвердити, що резервне повідомлення було надіслано і коли воно стало придатним для включення.
• Публікація стану: Записи Ethereum можуть показати, чи має міст необхідне право вимоги або вихідні дані для обробки виведення.
• Надзвичайні дії: Підписанти, що авторизують, уражені контракти та час транзакції визначають, чи змінили пауза або оновлення маршрут користувача.
• Забезпечення активів: Емітент токена та міст визначають, чи застосовується офіційне порівняння виведення до цього балансу.

Поширені запитання