Деталі Prysm: збій мережі Fusaka Mainnet та втрата 382 ETH

Вузли Prysm не змогли витримати високий навантаження на підтвердження під час Fusaka, що спричинило пропуск приблизно 18,5% слотів, низьку участь та втрати 382 ETH.

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

Prysm усунув цю проблему за допомогою конфігураційних прапорців та пізніших релізів, оновивши логіку валідації для запобігання повторного відтворення історичних станів.

Мережеве оновлення Ethereum Fusaka стикнулося з збоєм 4 грудня 2025 року після того, як вузли Prysm не змогли обробити підтвердження. Проблема виникла в основній мережі Ethereum під час вікна оновлення Fusaka, за участю команди клієнтів Prysm. Це сталося через виснаження ресурсів, що затримало відповіді валідаторів і спричинило пропуски епох, зниження участі та втрати нагород валідаторів.

Виснаження ресурсів порушує епохи Fusaka

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

На цьому діапазоні мережа втратила 248 блоків із 1 344 слотів. В результаті рівень пропущених слотів склав приблизно 18,5%. Участь у мережі також різко знизилася, опустившись до близько 75% під час пікових збоїв.

Валідатори зазнали вимірюваних втрат під час сповільнення. За даними команди Prysm, загальні втрати від пропущених нагород за підтвердження склали близько 382 ETH. Ці втрати накопичувалися через те, що валідатори не могли своєчасно подати докази.

Підтвердження, що виходять з синхронізації, спричинили важкі повторні обчислення

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

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

Один із прикладів — підтвердження, що посилається на блок 0xc6e4ff з епохи 411441. Prysm повторно відтворював кілька переходів стану для його перевірки. Варто зазначити, що інженери спостерігали цю поведінку майже 4000 разів у інфраструктурі.

Виправлення, виявлення та постійний моніторинг

Під час інциденту команда Prysm рекомендувала користувачам увімкнути прапорець --disable-last-epoch-target у версії 7.0.0. Це тимчасове рішення зменшило навантаження на повторне обчислення стану. Важливо, що воно уникнуло необхідності екстреного випуску клієнта.

Пізніше версії 7.0.1 і 7.1.0 запровадили постійні виправлення. Ці оновлення змінили валідацію підтверджень, щоб вона залежала від стану голови, уникаючи історичного повторного відтворення. Команда попередила проти використання прапорця --ignore-unviable-attestations.

Виявлення відбувалося за допомогою звітів від основних розробників і користувачів. Метрики показували зростання кількості повторних обчислень, високий рівень використання ресурсів і збій запитів gRPC. За даними Miga Labs, що цитуються Prysm, розподіл клієнтів змінився під час відновлення, підкреслюючи існуючі проблеми з різноманітністю.

Пост Prysm Деталі збою основної мережі Fusaka і втрати 382 ETH з’являється на Crypto Front News. Відвідайте наш сайт, щоб прочитати більше цікавих статей про криптовалюти, технології блокчейн і цифрові активи.