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

Нещодавно на консенсусному рівні Ethereum виникли короткочасні аномалії, що викликало широку увагу в галузі. У цій статті буде проведено глибокий аналіз цієї події.

Огляд події

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

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

Деталі події

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

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

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

Варто зазначити, що під час другого інциденту, через затримку в затвердженні, що перевищила встановлений поріг, було активовано механізм Inactivity leak консенсус-алгоритму Ethereum. Це призвело до конфіскації близько 28 ETH та невипуску близько 50 ETH.

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

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

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

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

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

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

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

У цьому випадку Ethereum продемонстрував свої переваги в дизайні:

1. Різноманітність клієнтів: різні реалізації клієнтів мають різний дизайн, і навіть якщо деякі клієнти мають проблеми, це не вплине на нормальну роботу інших клієнтів.

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

Досвід та прозріння

1. Різноманітність клієнтів потрібно покращити: наразі різноманітність клієнтів Ethereum все ще має простір для покращення, особливо виконавчі клієнти зосереджені на Geth, що становить 61%, що створює потенційні ризики.

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

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

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

5. Застосунковий рівень має бути готовим до реагування: Layer2, біржі, Oracle та інші застосунки повинні правильно обробляти ситуації з нестабільністю мережі, наприклад, відповідно подовжувати час підтвердження або призупиняти обслуговування.

Підсумок

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