Base переглядає подію переривання мережі: кошти користувачів не постраждали, вразливість виникла через логіку побудови блоків секвенсора.

Новина від Shenchao TechFlow, 27 червня, інженерна команда Base опублікувала звіт про аналіз інциденту призупинення виробництва блоків 25 червня.

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

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

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

Оскільки інші вузли не змогли перевірити та прийняти цей блок, процес консенсусу мережі був заблокований, що призвело до повної зупинки виробництва блоків у ланцюзі.

Під час інциденту Base не міг генерувати нові блоки Layer2, секвенсер і вузли валідації не могли обійти недійсний блок, а нові транзакції, подані користувачами, не могли бути завершені в ланцюзі.

Пізніше команда Base розгорнула патч для секвенсера, щоб забезпечити правильне оновлення стану журналу під час виконання, тим самим відновивши нормальну роботу мережі.

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