Валідаторам Ethereum рекомендують вимкнути Prysm через ризик застарілого стану

2025-12-04 05:58:54

Оператори валідаторів Ethereum, які використовують консенсусний клієнт Prysm, отримали термінове попередження 4 грудня. Команда Prysm підтвердила, що деякі ноди генерували старі стани для обробки застарілих атестацій. Це може призвести до неправильної поведінки при валідації, якщо це не виправити. Щоб запобігти цьому, Prysm порадила всім операторам негайно вимкнути певну функцію шляхом додавання одного прапорця до своєї beacon-ноди. Виправлення не потребує повного оновлення клієнта і не впливає на клієнти валідаторів.

Команда надала інструкцію операторам додати цей рядок: –disable-last-epoch-targets. Цей прапорець працює з Prysm v7.0.0, тобто більшість нод можуть застосувати виправлення за лічені хвилини. Попередження викликало швидку реакцію у спільноті валідаторів. Це пояснюється великою часткою Prysm у консенсусному шарі Ethereum.

Частка ринку Prysm робить це подією на рівні мережі

Дані MigaLabs показують, що Prysm контролює майже 20% ринку консенсусних клієнтів Ethereum, що робить його другим за розміром після Lighthouse. Такий масштаб перетворює баг на боці клієнта у проблему для всього ланцюга. Коли клієнт з такою часткою обробляє застарілі дані стану, це впливає не лише на одного валідатора. Це може призвести до:

Пропущених атестацій
Неправильних сигналів вибору форку
Зростання ризику штрафів або слешингу у крайніх випадках

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

Що саме сталося всередині Prysm

За словами команди Prysm, уражені ноди створювали непотрібні старі стани, намагаючись обробити застарілі атестації з попередніх епох. Така поведінка збільшує навантаження на CPU і пам’ять і може спотворювати те, як нода відстежує прогрес ланцюга під навантаженням. Подібна поведінка не є новою в історії Ethereum. Схожі проблеми з обробкою стану виникали під час:

Інциденту з фінальністю у травні 2023 року
Раніших багів з пошкодженням індексу бази даних
Минулого стрибка використання пам’яті в різних клієнтах

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

Що мають зробити валідатори просто зараз

Якщо ви використовуєте Prysm, перелік дій короткий і терміновий:

Додайте прапорець –disable-last-epoch-targets
Перезапустіть beacon-ноду
Перевірте логи на нормальний потік атестацій
Слідкуйте за пам’яттю та CPU після перезапуску

Зміни ключів валідатора не потрібні. Повна ресинхронізація не потрібна, виходити не потрібно. Для Ethereum загалом цей інцидент підтверджує відому істину: різноманітність клієнтів все ще має значення. Коли один клієнт займає майже 20% мережі, навіть керований баг стає подією з заголовків. Водночас ця подія показує зрілість операційних процесів Ethereum. Проблему було виявлено, оголошено та усунено протягом годин, а не днів. Саме так живий розрахунковий шар з капіталізацією понад $400 млрд залишається стійким. Наразі ланцюг залишається стабільним. Єдиний справжній дедлайн — для операторів Prysm швидко вжити заходів і увімкнути захисний перемикач.

ETH-3.69%

Переглянути оригінал

Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.