Аналіз короткочасних аномалій шарів консенсусу Ethereum протягом двох ночей

Нещодавно на шарі консенсусу Ethereum протягом двох ночей спостерігалися короткочасні аномалії. Аналіз показав, що це переважно було спричинено надмірним навантаженням на деякі клієнтські вузли шару консенсусу Ethereum, що призвело до відключення вузлів валідаторів. Це безпосередньо вплинуло на те, що голосування Epoch не змогло досягти необхідних 2/3, що ускладнило підтвердження фінальності на шарі консенсусу. Проте мережа швидко відновилася, що відображає хорошу стійкість та здатність до самовідновлення алгоритму консенсусу PoS Ethereum.

Огляд події

11 та 12 травня протягом двох ночей спостерігалося затримка у затвердженні Epoch мережі консенсусу Ethereum PoS:

• 11 травня: Затримка Epoch підтверджена приблизно на 20 хвилин (3 Epoch)
• 12 травня: Epoch затримка приблизно на 51 хвилину (8 Epoch)

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

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

У другій події, через те, що затвердження Epoch затягнулося понад встановлений поріг, було активовано механізм покарання алгоритму консенсусу Ethereum:

• Покарання для офлайн-валідаторів, зменшення приблизно на 28 ETH стейкінгових коштів
• Скасування винагороди за атестацію, приблизно 50 ETH не були видані
• Цей механізм забезпечує, що онлайн-валідатори врешті-решт можуть контролювати понад 2/3 стейкованих коштів, що дозволяє мережевому стану відновитися до нормального.

Аналіз причин

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

1. Коли вузол отримує свідчення (Attestation), яке вказує на застарілий блок, необхідно повторно обчислити стан сигнальної ланцюга для перевірки цих свідчень, що вимагатиме значних ресурсів ЦП і пам'яті.

2. Одночасно отримуючи велику кількість свідчень, що вказують на застарілі блоки, ресурси вузла вичерпуються, що призводить до виходу з ладу та відключення валідаторів.

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

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

Ethereum дизайн переваги

Ця подія підкреслила дві переваги Ethereum в дизайні:

1. Різноманітність клієнтів: Різниця в дизайні, реалізованому різними клієнтами, дозволила частині клієнтів (таким як Lighthouse) не зазнати впливу під час цього інциденту, що забезпечило безперервну роботу мережі.

2. Дизайн алгоритму консенсусу Gasper:

   • Розділіть виробництво блоків і підтвердження, навіть якщо підтвердження затримується, виробництво блоків все ще може продовжуватися.
   • Механізм витоку бездіяльності забезпечує досягнення консенсусу в мережі навіть у екстремальних умовах.

Досвід та висновки

1. Різноманіття клієнтів все ще потрібно зміцнити: Поточна різноманітність клієнтів Ethereum все ще має можливості для покращення. Якщо частка Prysm і Teku менше 1/3, ця подія, можливо, не відбулася б.

2. Механізм перемикання клієнтів потрібно вдосконалити: Коли виникають проблеми з певним клієнтом, як безпечно та ефективно перейти на інший нормальний клієнт, це питання, яке потребує вирішення.

3. Посилення моніторингу мережі консенсусу: Потрібно розробити послугу, подібну до Safe Head, яка постійно моніторитиме стан мережі Ethereum PoS, своєчасно виявляючи та попереджаючи про аномалії.

4. Посилити освіту користувачів: Поширення знань про механізм консенсусу PoS Ethereum, щоб уникнути виникнення у користувачів непотрібної паніки.

5. Вплив на рівні застосунків:

   • Час внесення депозитів з Layer1 до Layer2 може бути продовжено
   • Час поповнення на біржі може бути подовжено
   • Дані оракула можуть піддаватися ризику відкату
   • Додатки DeFi потребують відповідного коригування операційних стратегій

Підсумок

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