Почему сеть Base «замерзала» дважды за 48 часов — и насколько опасна архитектура с одним секвенсором?

Баг в логике сборщика блоков

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

Такой невалидный блок вызывал консенсусный сбой: секвенсор создал невалидный блок после номера 47 806 542, и сеть не могла генерировать следующие блоки. Операторы узлов не могли продолжать нормальную синхронизацию, пока проблема не была решена.

Хронология двух остановок

Второй сбой 26 июня описан как повторение того же класса ошибки, хотя сеть восстановилась быстрее.

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

Развёрнутое исправление

Инженеры Base применили патч к секвенсору, который обеспечивает корректное обновление journal state после неудачной транзакции. Исправление отслеживается в публичном pull request #3806 на GitHub.

После патча нормальная работа возобновилась, но Base рекомендовала операторам валидаторных узлов перезапустить или синхронизировать узлы заново. Команда отметила, что оба сбоя вызваны одним багом, а вторая, связанная проблема (PR #3805) привела к повторению инцидента на следующий день.

В результате Base отложила запуск запланированного апгрейда Beryl и активацию стандарта токенов B20 на один день для стабилизации сети.

Архитектура с одним секвенсором: более широкая проблема

Два сбоя подряд возобновили дискуссии об устойчивости дизайна Base с единственным секвенсором. Такая архитектура распространена среди многих оптимистичных роллапов, но создаёт явную единую точку отказа.

Ключевые опасения, поднятые в post-mortem и отраслевых публикациях:

• Единая точка отказа: Ошибка на уровне секвенсора может остановить выпуск всех блоков Base.
• Ручное восстановление: Для восстановления операторам узлов приходилось вручную перезапускать или синхронизировать узлы, а не полагаться на автоматическое самовосстановление сети.
• Риск надёжности: Два сбоя подряд поставили под вопрос надёжность быстрорастущей экосистемы L2, особенно в периоды высокой активности или запланированных обновлений.
• Планируемые улучшения: Base обещает усилить тестирование с помощью fuzz-тестов, тестов под нагрузкой, мониторинга и улучшенных инструментов восстановления, чтобы снизить вероятность повторения.

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