Автор: KarenZ, Foresight News
Пекинское время, 26 июня, ранним утром, Base дал рынку очень тихий урок по инфраструктуре.
Хронология этого простоя ясна:
- 0:03 утра: Base сообщает об аномальном состоянии формирования блоков в основной сети, команда расследует.
- 0:52 утра: Base определяет, что проблема в проблемном блоке, который мешает построению последующих блоков.
- 1:21 утра: Base локализовала проблему консенсуса, которая привела к упорядочиванию недействительного блока. Это сделало невозможным генерацию новых блоков после блока 47806542. Внутренний оркестратор и ноды предварительно восстановлены.
- 1:51 утра: Упорядочивание новых блоков восстановлено, внутренние ноды синхронизируются нормально.
- 1:58 утра: Base подтверждает, что здоровое построение блоков восстановлено, инфраструктура экосистемы может возобновить синхронизацию.
- 3:22 утра: Base дополнительно сообщает, что оркестратор и связанные системы стабильны, блоки генерируются нормально, и заявляет, что команда нашла коренную причину этого простоя, проверяет план исправления и впоследствии выпустит полный отчет с анализом.
Страница статуса Base показывает, что этот инцидент затронул депозиты, вывод средств, генерацию блоков и клиентское ПО основной сети Base.
Единственный активный оркестратор делает простой еще более заметным
Base — это Rollup, построенный на Ethereum. Он выполняет большое количество транзакций на L2, а затем отправляет необходимые данные и информацию о состоянии в Ethereum.
То, что пользователи ощущают ежедневно, — это не архитектурная схема, а то, могут ли транзакции попасть в блок, могут ли ноды синхронизироваться, нормально ли работают кошельки, обмены и межсетевые сервисы.
До запуска Flashblocks Base использовал систему оркестраторов с высокой доступностью: из 5 экземпляров оркестраторов один экземпляр выступал в роли лидера, отвечая за построение блоков и их распространение через P2P, остальные 4 служили подписчиками (follower), синхронизируя состояние цепи; если текущий лидер прекращал производить блоки, система выполняла переключение лидерства.
Эта конструкция показывает, что Base не был лишен резервирования. Проблема в том, что резервирование больше решает вопросы переключения при сбоях и доступности, но не эквивалентно одновременному участию нескольких независимых оркестраторов в создании блоков. Ежедневное производство блоков по-прежнему несет текущий лидер. Как только возникают проблемы с консенсусом, упорядочиванием или синхронизацией узлов, пользователи в первую очередь чувствуют, что новые блоки перестают генерироваться.
После запуска Flashblocks построение блоков в Base получило дополнительный уровень механизма предподтверждения на уровне 200 миллисекунд. В документации Base указано, что Flashblocks всегда включен на Base, все блоки строятся Flashblocks builder; приложения могут выбирать, использовать ли данные предподтверждения, или продолжать ожидать обычного подтверждения блока за 2 секунды через стандартный RPC. Другими словами, Flashblocks уже является частью инфраструктуры для текущего построения блоков Base, но для подключения приложений к опыту предподтверждения это опционально.
Объяснение на странице состояния безопасности Base более конкретное: проблема консенсуса привела к упорядочиванию недействительного блока, что, в свою очередь, помешало генерации новых блоков после блока 47806542. Истинную причину еще предстоит дождаться в полном отчете официальных лиц.
Предыдущий простой Base был вызван невозможностью успешной конфигурации нового оркестратора
Это не первый раз, когда Base прерывает генерацию блоков из-за проблем, связанных с оркестратором. 5 августа 2025 года в основной сети Base произошел 33-минутный сбой сети. В последующем анализе официальные лица заявили, что активный оркестратор начал испытывать задержки из-за активности в цепи, Conductor, отвечающий за управление кластером высокой доступности (HA), автоматически переключил лидерство на новый оркестратор; однако новый оркестратор в то время все еще находился в процессе настройки и не мог производить блоки, и, поскольку Conductor еще не был полностью включен на этом оркестраторе, система не смогла инициировать следующее переключение. Затем команда вручную приостановила HA и передала лидерство здоровому оркестратору, после чего полностью восстановила работу.
Сопоставление двух инцидентов требует осторожности: проблема августа 2025 года указывала на процесс переключения высокой доступности оркестратора, сегодняшний же инцидент с простоем вызван проблемой консенсуса, которая привела к упорядочиванию недействительного блока и помешала генерации новых блоков после блока 47806542.
Они вместе указывают на одну реальность: L2 могут полагаться на Ethereum в вопросах доступности данных, урегулирования, безопасности и окончательности, но ежедневная доступность сильно зависит от оркестратора и связанных операционных систем. Пока новые блоки не могут генерироваться, пользователи видят, что транзакции останавливаются в пути.
Настоящий простой произошел вблизи окна запуска B20
Временная точка происшествия微妙на. Base в тот момент находился вблизи окна обновления Beryl.
Первоначально активация основной сети Beryl была запланирована на 2:00 утра по пекинскому времени 26 июня, в настоящее время перенесена на 2:00 утра 27 июня.
Ключевое содержание Beryl включает три пункта: введение нативного стандарта токенов B20, сокращение окончательного срока подтверждения вывода средств с одного доказательства с 7 дней до 5 дней, а также снижение использования дискового пространства до 50% и повышение пропускной способности примерно на 33% через Reth V2.
Разница B20 заключается в реализации на низком уровне. В отличие от ERC-20, которые в основном развертываются в форме смарт-контрактов EVM, B20 реализован через Rust precompile и создается через одиночку (singleton) B20Factory. Он также имеет встроенные возможности управления ролями, ограничения предложения, mint/burn, приостановки, стратегий перевода, memo и ERC-2612 permit. Проще говоря, Base превратил множество базовых функций токенов, которые эмитенты создавали, аудировали и поддерживали снова и снова, в цепочный инструментарий.
B20 легче всего вызывает рыночные ассоциации, и даже некоторые пользователи сообщества связывают его с выпуском токена Base. Однако B20 обсуждает, «как другим более стандартизированно выпускать активы на Base»; выпуск токена Base обсуждает, «будет ли Base в будущем вводить собственный сетевой токен».
Первое уже включено в обновление Beryl, второе все еще остается темой, волнующей рынок, но официально не объявленной.
Этот простой сделает обсуждение выпуска токена Base более реалистичным. Рынок раньше спрашивал: выпустит ли Base токен, когда и как распределит аирдроп. После инцидента более стоит спрашивать: если в будущем действительно будет введен сетевой токен, каким обязанностям он должен соответствовать? Децентрализации оркестратора, управленческим ограничениям, бюджету безопасности или распределению прав и обязанностей при реагировании на инциденты?
