Base подвел итоги инцидента с перебоем в сети: средства пользователей не пострадали, уязвимость связана с логикой построения блоков секвенсора.

Шэньчао TechFlow, 27 июня, инженерная команда Base опубликовала отчет о восстановлении после инцидента с остановкой производства блоков 25 июня.

В отчете указано, что на основной сети Base произошло два сбоя производства блоков: 25 июня в 11:47 и 26 июня в 11:28 по восточному времени США, продолжительностью 116 и 20 минут соответственно. Официальные лица заявили, что обе аварии были вызваны одной и той же технической проблемой, целостность цепочки не пострадала, а средства пользователей всегда были в безопасности.

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

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

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

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

Затем команда Base развернула исправление для секвенсора, чтобы обеспечить правильное обновление состояния журнала во время выполнения, восстановив тем самым нормальную работу сети.

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