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 не поширюється на базовий блокчейн.