Мережа Base зупинялася двічі за 48 годин: баг секвенсора та ризики єдиної точки відмови

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

Хронологія зупинок

Друга зупинка 26 червня сталася через ту саму помилку виробництва блоків, але мережа відновилася швидше.

Під час обох інцидентів нові блоки не створювалися, що порушувало обробку транзакцій. Однак кошти користувачів не постраждали.

Виправлення

Інженери Base застосували патч до секвенсора, який забезпечує належне оновлення стану журналу після невдалої транзакції. Виправлення доступне в публічному pull request на GitHub (#3806).

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

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

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

Послідовні зупинки знову активізували дискусію про надійність архітектури Base з єдиним секвенсором, яка поширена серед оптимістичних ролапів, але створює єдину точку відмови.

Основні занепокоєння, висловлені у звіті та галузевих публікаціях:

• Єдина точка відмови: Помилка секвенсора може зупинити все виробництво блоків Base, заморозивши мережу.
• Ручне відновлення: Для відновлення операторам доводилося вручну перезапускати або пересинхронізувати вузли, а не покладатися на автоматичне самовідновлення.
• Ризик надійності: Послідовні збої викликали питання щодо надійності масштабованої екосистеми L2, особливо в періоди високої активності або запланованих оновлень.
• Заплановані покращення: Base пообіцяла посилити тестування за допомогою fuzz-тестів, навантажувальних тестів, моніторингу та кращих інструментів відновлення, щоб зменшити ймовірність повторення.

Інцидент показав, що навіть найбільші Ethereum L2-мережі можуть бути виведені з ладу через крайовий випадок управління станом в одному секвенсорі. Автоматичне перемикання на резерв та системи відновлення все ще залишаються в роботі в усій екосистемі ролапів.