Розробники Ethereum об’єднали виправлення недоліку обробки депозитів у майбутньому оновленні Glamsterdam, який міг дозволити будівельнику блоку отримати ETH, призначені для нового валідатора, після початкового рішення відхилити запропоновану зміну.
Резюме
- Ethereum об’єднав виправлення обробки депозитів Glamsterdam 26 жовтня.
- Недолік міг зарахувати стейкінгові депозити будівельникам, які мають той самий публічний ключ.
- Розробники спочатку відхилили виправлення, перш ніж схвалити додаткові тести.
- Окреме розслідування сумісності контрактів затримало активацію Glamsterdam у Hoodi.
Згідно з специфікаціями консенсусу Ethereum, супроводжувач Justin Traglia об’єднав виправлення 26 жовтня після того, як розробник avsetsin виявив проблему з тим, як оброблятимуться очікувані депозити під час форку Gloas. Зміна відокремлює депозити будівельників від депозитів валідаторів відповідно до їхніх облікових даних для виведення, запобігаючи потраплянню коштів на неправильний рахунок, коли обидва використовують той самий публічний ключ.
Уразливість стосувалася правил, що перебувають у розробці, а не підтвердженого викрадення з основної мережі Ethereum. Розробники включили виправлення до специфікацій, хоча окремим клієнтам консенсусу все ще потрібно реалізувати та протестувати переглянуту поведінку.
Недолік Ethereum Glamsterdam виявив ризик для депозитів валідаторів
Проблема виникла через зміни, заплановані в межах закріпленого розділення пропонера та будівельника Glamsterdam, яке призначає побудову блоків і пропозицію блоків різним ролям. Будівельники збирають корисні навантаження транзакцій, тоді як валідатори беруть участь у пропозиції та підтвердженні блоків через систему доказу частки Ethereum.
Дослідник avsetsin описав недолік 12 жовтня, виявивши проблему в правилах, які використовуються для обробки депозитів, що очікують під час оновлення мережі. Якщо будівельник зареєструвався з використанням публічного ключа до того, як надійшов депозит валідатора під тим самим ключем, запропонована логіка могла зарахувати обидва депозити будівельнику.
Дослідник окреслив сценарій, у якому оператор стейкінгу отримує кошти від протоколу ліквідного стейкінгу для створення нового валідатора. Зареєструвавшись спочатку як будівельник, оператор міг спричинити потрапляння депозиту валідатора протоколу до балансу будівельника, де адреса для виведення могла перебувати під контролем оператора.
«Оператор може вивести кошти протоколу», — попередив avsetsin у звіті на GitHub.
Оскільки очікуваний валідатор не буде створений, стейкінговий сервіс може зазнати труднощів з отриманням доказу, необхідного для завершення його звичайних процедур депозиту та відновлення.
Дослідник вивчив потенційну експозицію, пов’язану з Lido, Origin і Rocket Pool, шляхом попереднього дослідження коду. Ці висновки були умовними щодо того, як окремі протоколи обробляли депозити, і звіт не встановив, що проєкти зазнали експлуатації.
Розробники скасували рішення після подальшого розгляду
Запропоноване виправлення спочатку зустріло опір з боку розробників клієнтів Ethereum, незважаючи на опис дослідником ризику маршрутизації депозитів. 19 жовтня Traglia закрив pull-запит після обговорень серед основних розробників.
«На той час було недостатньо підтримки з боку клієнтів, щоб внести цю зміну», — написав Traglia.
Рішення не залишилося чинним, і розробники знову відкрили пропозицію 23 жовтня після подальшого вивчення.
Згодом рецензент potuz схвалив підхід, але попросив більше тестів для конкретних комбінацій депозитів. Avsetsin додав ці тести 23 жовтня, охопивши випадки, коли депозити будівельника та валідатора мають спільний публічний ключ, але потребують окремої обробки.
Остаточна зміна була об’єднана в специфікації консенсусу Ethereum 26 жовтня після подальшого огляду клієнтів. Вона спрямовує дійсні депозити валідаторів до черги валідаторів, дозволяючи легітимним депозитам будівельників реєструватися або додавати кошти до існуючого будівельника.
Нові правила розрізняють депозити за обліковими даними для виведення, які визначають дозволені механізми виведення. Вони зберігають окремі записи будівельника та валідатора навіть там, де той самий публічний ключ з’являється в обох ролях.
Затримка Hoodi дає розробникам більше часу для дослідження
Оновлення специфікації з'явилося, коли розробники Ethereum розглядали окрему проблему, що впливає на заплановану активацію Glamsterdam у тестовій мережі Hoodi. Фонд Ethereum відклав оновлення, заплановане на 26 жовтня, після того, як дослідники виявили ризики сумісності, пов'язані з EIP-8037.
Як crypto.news раніше повідомляв про відтермінування, це рішення вилучило як зміни виконання Amsterdam, так і зміни консенсусу Gloas із запланованої активації в Hoodi. Запропоноване збільшення ліміту газу до 200 мільйонів було відкладено разом із ними.
Дослідник Ethereum Тоні Варштеттер пояснив, що EIP-8037 може перешкоджати смарт-контрактам, які покладаються на припущення щодо залишку газу під час виконання. Він виявив випадки, коли облік газу міг спричинити неочікуваний відкат транзакції або дозволити шлях виконання, який розробники вважали недосяжним.
Проблема сумісності контрактів відрізняється від дефекту депозиту білдера, виправленого в корекції на GitHub. Обидві стосуються Glamsterdam, але відтермінування Фондом 22 жовтня конкретно посилалося на подальше дослідження взаємодії EIP-8037 з існуючими контрактами.
Клієнти Ethereum повинні впровадити переглянуті правила
Glamsterdam уже активовано в тестовій мережі Sepolia 6 жовтня, де розробники досліджували зміни побудови блоків і вищу пропускну здатність обробки транзакцій. Наступна репетиція в Hoodi залишається незапланованою, без підтвердженої дати активації в основній мережі Ethereum.
Об'єднана корекція депозиту містить регресійні тести, що охоплюють те, як депозити класифікуються під час переходу Gloas. Команди клієнтів повинні включити зміну специфікації у своє програмне забезпечення та завершити подальше тестування, перш ніж оновлені правила зможуть працювати під час майбутнього оновлення мережі.
