Детали инцидентов 25 и 26 июня
Сбои сети Base, зафиксированные 25 и 26 июня, были вызваны дефектом в логике секвенсора Ethereum-решения второго уровня. После того как транзакция завершилась ошибкой, механизм не очистил временное состояние, из-за чего следующая корректная операция получила неверный расчет комиссии. Итогом стало формирование блока с некорректным переходом состояния, который остальные ноды сети не смогли принять.
Первый инцидент продолжался 116 минут, второй — 20 минут. На протяжении этих промежутков времени сеть не выпускала новые блоки, транзакции не попадали в блокчейн, а очередь неподтвержденных операций переполнилась. Пользователи получали ошибки при отправке новых транзакций, однако команда подчеркнула, что средства оставались в безопасности и не пострадали.
Технические причины остановки производства блоков
Согласно опубликованному отчету, корень проблемы заключался в некорректной обработке ошибок секвенсором. Компонент не очистил journal state — временное состояние системы, — и следующая транзакция получила ошибочный расчет комиссии. Сформированный блок содержал недействительный переход состояния, что привело к полной остановке производства блоков.
После установки исправления разработчики столкнулись со второй ошибкой: «состояние гонки», или race condition, при перезапуске кластера секвенсоров. Эта проблема помешала узлам быстро синхронизироваться и стала причиной повторного, более короткого сбоя на следующий день. Race condition означает ситуацию, когда несколько параллельных процессов конкурируют за ресурсы и результат выполнения зависит от непредсказуемой последовательности их исполнения.
Запланированные изменения в сети Base
После инцидента команда Base объявила об усилении стресс-тестирования и фаззинга протокола. Фаззинг — это метод тестирования, при котором в систему подаются случайные или некорректные данные для выявления нестандартных сценариев обработки транзакций. Такие меры направлены на обнаружение ошибок до их проявления в боевой среде.
Разработчики также намерены улучшить мониторинг сети и внедрить механизм graceful recovery — «плавного восстановления». Этот механизм позволит быстрее возвращать сеть к работе после подобных сбоев, минимизируя время простоя. Сообщается, что в феврале команда Base отказалась от технологического стека Optimism и перешла на собственную унифицированную архитектуру сети, что может повысить контроль над надежностью инфраструктуры в будущем.