« Не вітряк крутиться, а вітер дме», — казав Едгар Фактор. Розробники Ethereum щойно відчули це на собі з Glamsterdam. 19 жовтня було відхилено патч, який захищає стейкінг-депозити, через брак підтримки з боку клієнтських команд, але 26 жовтня його було інтегровано до специфікацій оновлення.
Вітер змінився разом із календарем. Відтермінування Glamsterdam на тестовій мережі Hoodi надало командам часу, якого їм бракувало, для виправлення правила депозиту. Це правило дозволило б оператору отримати ETH, призначений для валідаторів таких протоколів, як Lido чи Rocket Pool.
Ключові моменти
- Оператор міг би зарахувати на свій обліковий запис конструктора ETH, внесений стейкінг-протоколом для запуску валідатора.
- Патч (PR #5736) тепер сортує очікуючі депозити за їхніми ідентифікаторами виведення.
- Відхилений 19 жовтня, він був повторно відкритий 23-го на запит Lido, а потім об’єднаний 26-го.
- Жодних втрат: вразливість стосувалася специфікацій, які ще не працюють у основній мережі.
Glamsterdam: вразливість, що загрожувала стейкінг-депозитам
Все починається з ePBS (EIP-7732) — розділення між провайдером і конструктором блоків, яке Glamsterdam вносить до протоколу. Конструктори, ці спеціалізовані учасники, які збирають блоки, мають тут власний обліковий запис. Він поповнюється депозитом ETH, так само, як запускається валідатор.
Проблема виникає під час переходу. Депозити, що ще перебувають у черзі на момент активації форку, мають бути розподілені між валідаторами та конструкторами. Однак чернетка специфікацій передбачала дуже просте правило: щойно депозит зареєстрував конструктора для певного публічного ключа, всі наступні депозити за цим ключем йшли до нього.
12 жовтня Джордж Авцесін, головний архітектор протоколу Lido, описав сценарій у квитанції GitHub. Оператор спочатку реєструє конструктора з новим ключем. Потім стейкінг-протокол вносить ETH для запуску валідатора під цим самим ключем.
Якщо обидва депозити ще в очікуванні на момент форку, обидві суми потрапляють до конструктора. «Оператор може вивести кошти протоколу», — підсумовує Авцесін.
І пастка закривається. Оскільки жоден валідатор не створюється, протокол, що зазнав збитків, не може надати доказ, який дозволив би йому повернути свої внески.
Авцесін ретельно дослідив контракти Lido, Rocket Pool та Origin за допомогою того, що він називає «швидким пошуком за допомогою ШІ». Він ретельно підкреслює «умовні результати», а не підтверджені експлойти. Вже наявні запобіжники, які відхиляють попередній депозит конструктора, могли б навіть заблокувати атаку.
Патч, відхилений клієнтами, а потім врятований Lido
Парадоксально, але рішення полягає в одному реченні. З pull request #5736 кожен очікуючий депозит сортується за його ідентифікаторами виведення (withdrawal credentials). Депозит, призначений для валідатора, залишається у валідатора, навіть якщо конструктор використовує той самий ключ.
Але зміна логіки депозитів за кілька тижнів до форку викликає занепокоєння. Після двох звернень від розробників, Джастін Тралья, відповідальний за специфікації консенсусу, закрив питання 19 жовтня. «Не було достатньої підтримки з боку клієнтів, щоб внести цю зміну зараз», — написав він.
Це відхилення не означало остаточного поховання. Звернення All Core Devs проводяться без формального голосування: пропозиції просуваються шляхом приблизного консенсусу. Відхилена тема повертається, щойно змінюється контекст.
Контекст змінився 22 жовтня. Розробники скасували активацію Glamsterdam на Hoodi, заплановану на 26-те, після аналізу ChainSecurity щодо нових правил ціноутворення на газ (EIP-8037 та EIP-8038).
Наступного дня Дмитро Гусаков, керівник відділу стейкінг-інжинірингу Lido, попросив повторно відкрити квитанцію «через зміни в графіку Glamsterdam». Потуз, розробник клієнта Prysm, підтвердив того ж дня. Хоча й з певними застереженнями.
«Я все ще боюся розміщувати цю зміну перед форком», — попередив він. Однак, з огляду на те, що форк тепер без дати, він вважав, що має «більш ніж достатньо часу», щоб вивчити його вплив на специфікації та кеші клієнтів.
Ніко Флаіг, інженер ChainSafe, дав зелене світло 26 жовтня після успішних тестів на клієнті Lodestar. Джастін Тралья одразу ж об’єднав патч. Ця зміна приєдналася до основної гілки репозиторію, отже, до списку змін, які кожен клієнт повинен буде реалізувати перед форком.
Glamsterdam: який графік для основної мережі Ethereum
Цей патч нічого не змінює у двох головних аспектах Glamsterdam. ePBS має покласти край довірі, яку валідатори наразі надають релеям MEV-Boost, що працюють поза протоколом приватними учасниками.
Списки доступу на рівні блоків (EIP-7928) вимагають від кожного блоку перелічувати місця зберігання, які він читає та модифікує. Таким чином, вузли можуть паралельно виконувати транзакції та завантажувати стан заздалегідь, що готує ґрунт для більших блоків.
Оновлення працює на Sepolia з 6 жовтня. Hoodi тепер має отримати нову дату, перш ніж можна буде говорити про основну мережу. Однак у порядку денному дзвінка від 22 жовтня були зазначені 1, 8 та 9 грудня як можливі дати, за умови, що Hoodi пройде без проблем.
Під сонцем Ethereum нічого нового. EIP-3074 був вилучений з Pectra у травні 2024 року на користь EIP-7702, написаного Віталіком Бутеріним двома тижнями раніше. Dencun і Pectra також ковзнули на кілька місяців від своїх початкових графіків.
Для стейкерів справа виходить за межі суперечки фахівців. Lido, Rocket Pool та інші протоколи ліквідного стейкінгу керують мільйонами ETH, довіреними їхнім користувачам, і саме інженер Lido підняв це питання. Від часу The Merge Ethereum послідовно пройшов Shapella, Dencun, Pectra та Fusaka, не перериваючи видобуток блоків. Glamsterdam з тією ж обережністю просувається тестовими мережами.
За даними порталу: journalducoin.com