Base: два сбоя за неделю. Что показал пост-мортем?

Сеть Base, layer-2 блокчейн от Coinbase, за прошедшую неделю останавливалась дважды: сначала на 116 минут в четверг, затем на 20 минут в пятницу. В субботу команда опубликовала пост-мортем и объяснила причину обоих сбоев.

Что такое секвенсер и почему он настолько критичен?

Большинство layer-2 сетей передают управление порядком транзакций одному компоненту. Он принимает транзакции от пользователей, определяет их последовательность и формирует блоки. Этот компонент называется секвенсером. Base работает по той же схеме.

Общая идея layer-2 состоит в том, чтобы обрабатывать транзакции за пределами основного блокчейна, а затем публиковать лишь сжатые итоги на Ethereum mainnet. Это дает скорость и низкие комиссии. Base является оптимистичным роллапом (optimistic rollup). Такие сети считают транзакции валидными по умолчанию и позволяют их оспорить в течение определенного времени.

Но есть и обратная сторона. Один сбой в секвенсере парализует всю сеть. Нет резервного узла, нет переключения. Если он выходит из строя, новые блоки просто не генерируются. Именно это произошло на прошлой неделе. Похожие случаи ранее происходили на Arbitrum, OP Mainnet и zkSync Era.

Для пользователя сбой выглядит одинаково: транзакции отправляются, но подтверждения не приходят. Средства никуда не исчезают, но сеть не движется. В случае Base первый сбой длился более двух часов.

Где прятался баг?

Каждая транзакция, которую принимает секвенсер, проходит проверку перед включением в блок. Если транзакция невалидна, она отклоняется. Вместе с этим система должна очищать внутренний "журнал состояния" (journal state). В нем фиксируется, какие аккаунты и слоты хранилища затрагивала транзакция во время выполнения.

Баг был в том, что очистка не происходила. После отклонения транзакции журнал оставался незачищенным. Информация об аккаунтах и слотах хранилища оставалась в памяти секвенсера. При следующей попытке построить блок система натыкалась на это остаточное состояние и зависала. Секвенсер не мог двигаться дальше, пока кто-то не перезапустит процесс вручную.

Отклонение невалидной транзакции отработало корректно. Она не попала в блок. Но сопутствующий шаг при отклонении (очистка журнала) просто не срабатывал. Эти два шага были разорваны между собой, хотя должны были быть неразрывно связаны. Патч, исправивший первый сбой, обеспечил правильную очистку после каждого отклонения. Изменение простое на бумаге, но для его проявления нужен очень конкретный сценарий, и именно поэтому его не обнаружили раньше.

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

- команда Base Engineering, из пост-мортема от 28 июня 2026 года

Как развивались два сбоя

Оба сбоя произошли в течение двух дней. Первый случился в четверг и длился 116 минут. Второй случился в пятницу и длился 20 минут, но уже по другой причине.

• Четверг, первый сбой: 116 минут простоя. Секвенсер зависал из-за остаточного состояния в памяти после невалидной транзакции.
• Команда обнаружила проблему, подготовила патч и перезапустила секвенсер. Сеть восстановилась.
• Но при восстановлении возникло "состояние гонки" (race condition). После сброса системы узлы-валидаторы не успевали синхронизироваться с секвенсером.
• Пятница, второй сбой: 20 минут простоя из-за race condition. Для полного восстановления потребовался ручной перезапуск узлов.

Что Base планирует изменить?

Команда объявила два направления улучшений. Первое охватывает масштабное "fuzz testing". Систему намеренно бомбардируют большим количеством некорректных, случайных или непредвиденных входных данных. Это помогает выявлять граничные случаи и баги до того, как они попадают в продакшн. По словам команды, предыдущий объем тестирования оказался недостаточным для покрытия такого сценария.

Второе направление охватывает так называемое "graceful recovery". Сейчас после сбоя узлы-валидаторы требуют ручного перезапуска от инженеров. Именно поэтому второй сбой в пятницу не завершился быстрее. Новая функция должна позволить узлам восстанавливаться автоматически после нестандартных ситуаций, без участия человека.

Зависят ли layer-2 от единственного уязвимого места?

Децентрализация секвенсера стоит в повестке большинства L2-проектов уже несколько лет. Но на практике никто до нее полностью не дошел. Пока секвенсер остается единственным централизованным компонентом, сбои такого типа остаются возможными на любом layer-2.

В индустрии обсуждают "distributed sequencing": группу независимых операторов вместо единственного секвенсера. Если один оператор падает, другие продолжают работу. Но такое решение усложняет архитектуру и может снижать скорость сети, поэтому ни один крупный L2 его пока не внедрил.

Для Base это не первый подобный сбой. В сентябре 2024 года сеть стояла 17 минут, в августе 2025 простой длился около 30 минут. Каждый раз команда реагировала и исправляла конкретную ошибку. Но системная проблема (зависимость от единственного секвенсера) остается нерешенной.

Base занимает второе место среди layer-2 по сумме заблокированных активов: около 11 млрд долларов по данным L2beat. При таком масштабе каждая остановка ощутима. Во время простоя не могли обрабатывать транзакции все протоколы, развернутые на Base, включая Uniswap и другие DeFi-приложения. Транзакции на Ethereum mainnet при этом не останавливались. Сбой на уровне layer-2 не распространяется на базовый блокчейн.