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

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

Огляд подій

Зазвичай стан мережі консенсусу Ethereum PoS буде затверджено протягом 2-х епох. Але минулого тижня сталося двічі затримка затвердження епох:

• 11 травня: Epoch затримано на 3 Epoch, приблизно на 20 хвилин.
• 12 травня: Epoch затримка на 8 Epoch, приблизно 51 хвилина.

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

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

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

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

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

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

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

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

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

• Свідчення вказує на застарілий слот
• Свідчення вказує на контрольну точку, яку вузол ніколи не бачив.

Переваги дизайну Ethereum

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

1. Різноманітність клієнтів Ethereum
2. Проектування алгоритму Gasper

Різноманітність клієнтів Ethereum

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

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

Дизайн алгоритму консенсусу Gasper щодо доступності

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

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

Крім того, другий інцидент активував механізм Inactivity Leak, який розроблений для забезпечення того, щоб Ethereum міг знову підтверджувати блоки навіть у крайніх ситуаціях, коли ( велика кількість валідаторів залишається офлайн протягом тривалого часу ).

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

Виклики багатоклієнтності Ethereum

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

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

• Безпечно перенесіть ключі верифікації проблемного клієнта на нормальний клієнт
• Забезпечте узгодженість поведінки старого та нового клієнтів, щоб уникнути покарання

Моніторинг консенсусу Ethereum

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

Популяризація алгоритму консенсусу Ethereum

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

Проекти на основі Ethereum

Хоча мережа Ethereum достатньо міцна, час від часу нестабільність може впливати на додатки. Додатки повинні правильно обробляти ці нестабільні ситуації:

• Час внесення депозитів з Layer1 на Layer2 може подовжитися
• Час поповнення на біржі може бути подовжено
• Існує ризик відкату цінових пропозицій на Oracle-ланцюгу, тому високовартісні послуги, що покладаються на них, слід відповідно призупинити.
• Деякі DeFi-додатки можуть вимагати призупинення частини функцій

Підсумок

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