Ethereum L2 Network Starknet: Postmortem Analysis of Mainnet Outage

На цьому тижні мережа Layer 2 Starknet на Ethereum зазнала збою основної мережі. Згідно з звітом про задне аналізу, опубліковано 11 січня, інцидент виник через невідповідність стану між шаром виконання (blockifier) та шаром доказування. За певної комбінації міжфункційних викликів і відката, шар виконання помилково записав стан, який мав бути відкачений, що призвело до аномалії виконання транзакцій. Хоча відповідні транзакції не отримали остаточного підтвердження на L1, подія спровокувала переорганізацію блоків, і прибл. 18 хвилин активності в мережі було відкачено. Що ще більш тривожить, це вже другий серйозний інцидент перерви Starknet з 2025 року.

Технічні деталі: “Розсинхронізація” між шаром виконання та шаром доказування

Коренева причина інциденту

Технічна причина цього збою відносно складна. Архітектура Starknet включає два ключові рівні: шар виконання, відповідальний за обробку логіки транзакцій, та шар доказування, відповідальний за генерування доказів з нульовим розголошенням та подання їх у мережу Ethereum. Під час цього інциденту, коли з’ялася певна комбінація викликів функцій та операцій відката, шар виконання (blockifier) помилково записав запис про стан, який мав бути відкачений, що спричинило конфлікт стану між двома рівнями.

Добра новина полягає в тому, що шар доказування коректно ідентифікував цю помилку, відхилив проблемну транзакцію та не подав її до реєстру. Цей механізм “саморегуляції” запобіг перманентизації помилкового стану в основну мережу Ethereum.

Чому була необхідна переорганізація

Через невідповідність між шаром виконання та шаром доказування мережа була змушена виконати переорганізацію блоків для відновлення нормального стану. Ця переорганізація спричинила откату прибл. 18 хвилин активності мережі, і користувачі повинні були повторно подати транзакції. Для нечасті за часом транзакцій вплив був мінімальним, але для частих трейдерів або операцій, що вимагають швидкого виконання (наприклад, екстрене закриття позицій), це могло спричинити реальні втрати.

Історичне порівняння: Проблеми стають все більш частими

Хоча час відката цього разу був коротший (18 хвилин проти 1 години), проблема з частотою починає проявлятися. Від вересня до січня Starknet пережив два серйозні перерви менше ніж за пів року, і типи збоїв були різними, що відображає потенційні ризики в різних рівнях системи.

Відповідь команди та зобов’язання

Негайні дії

Команда Starknet одночасно з опублікуванням звіту про задне аналізу дала кілька зобов’язань:

• Посилити процеси тестування коду, особливо тестування граничних умов та складних сценаріїв
• Посилити механізм перегляду коду для запобігання подібним проблемам невідповідності стану
• Згідно з相關 інформацією, Starknet планує запустити версію v0.14.1 з оновленням хеш-функції та швидшим генеруванням блоків та іншими оптимізаціями

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

Оцінка впливу на екосистему

На рівні користувачів

Фактичний вплив цього інциденту був відносно обмежений, тому що:

• Час відката був короткий (18 хвилин), кількість постраждалих транзакцій була відносно невелика
• Транзакції не отримали остаточного підтвердження на L1, тому реальних втрат коштів не було
• Користувачам майже потрібно було лише повторно подати транзакції, а не зіткнутися зі втратами активів

На рівні екосистеми

Проте з ширшої перспективи, частих перерви становлять виклик розвитку екосистеми Starknet:

• Зменшує впевненість користувачів у стабільності мережі
• Може впливати на готовність додатків DeFi до розгортання
• Створює невигідне становище у конкуренції з іншими проектами L2 (такими як Arbitrum, Optimism)

Варто відзначити, що згідно з доступною інформацією, Starknet активно розширює сценарії застосування, наприклад, співпраця з Noon на запуск Bitcoin Vault, співпраця з AlchemyPay та іншими проектами. Питання, чи зможе цей розвиток екосистеми компенсувати негативний вплив проблем зі стабільністю, є центром уваги для подальшого спостереження.

Висновок

Цей збій Starknet відображає технічні виклики мережі L2 в складних сценаріях. Цей інцидент скоріше демонструє недостатність системи у обробці граничних умов, ніж бути серйозною уразливістю безпеки. Механізм “саморегуляції” шару доказування ефективно запобіг втратам коштів, але частих перерви не можна ігнорувати.

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