Інженер Lido попереджає про ризик перехоплення депозитів стейкінгу під час переходу ethereum на Glamsterdam

Інженер Lido попереджає про ризик перехоплення депозитів стейкінгу під час переходу ethereum на Glamsterdam

Кастомне зображення

Чому розробники ethereum відхилили виправлення на рівні протоколу

Наступна велика оновлення мережі ethereum спрямоване на масштабування базового рівня за допомогою вбудованого розділення пропозал-білдерів та вищих лімітів газу, але специфічна для часу вразливість привернула нову увагу одного з найбільших ліквідних стейкінг-провайдерів. 20 жовтня 2026 року Дима Гусаков, керівник інженерії Lido Finance, публічно деталізував, як перехід до Glamsterdam може дозволити зловмисному оператору ноди випередити депозит валідатора стейкера. Атака використовуватиме депозити білдера з відводними реквізитами, що починаються з 0xB0, які тимчасово ділять чергу депозитів, що потенційно зарахує ETH на акаунт білдера замість активації призначеного валідатора. Часове вікно обмежене самим переходом на хард-форк. Після оновлення депозити білдера перейдуть до окремого шляху контракту.
 
Пропонований виправлення на рівні протоколу в специфікаціях консенсусу було закрито як «не планується», переклавши відповідальність за захист на стейкінг-протоколи. Ця стаття досліджує технічні механізми ризику, вибір дизайну оновлення, що створив тимчасове перекриття, причини, чому розробники ядра відмовилися від патча протоколу, практичні кроки, які повинні зробити провайдери ліквідного стейкінгу, терміни тестнету, які залишають операторам лише кілька днів на підготовку, а також ширші висновки щодо безпеки делегованого стейкінгу по мірі просування Ethereum своєї дорожньої карти масштабування. Аналіз базується виключно на матеріалах та первинних заявленнях за останні 30 днів, зосереджуючись на підтверджених деталях, а не припущеннях.

Лідер інженерного напрямку Lido розкриває вектор фронт-ранінгу в X та на розробницьких зустрічах

Дима Гусаков виступив із попередженням 20 жовтня 2026 року, звернувшись безпосередньо до стейкінг-протоколів та делегованих стейкерів. Він пояснив, що оператор ноди може подати депозит будівельника, використовуючи той самий публічний ключ, перш ніж легітимна транзакція депозиту валідатора буде зафіксована. Оскільки Glamsterdam вводить депозити будівельника, які ґрунтуються на відкликаннях з префіксом 0xB0, і оскільки ці депозити ділять чергу депозитів валідатора під час переходу, перший дійсний депозит може отримати кошти. В результаті валідатор стейкера ніколи не з’являється на beacon chain, тоді як ETH зараховується на акаунт будівельника нападника. Гусаков підкреслив, що атака можлива лише на момент форку. До Glamsterdam депозити будівельника проходять через існуючу чергу депозитів валідатора; після цього вони маршрутизуються через окремий контракт. Він зазначив, що обмежений термін робить виявлення та запобігання можливими для підготовлених протоколів.
 
Та сама проблема виникла на зустрічі All Core Devs Consensus (ACDC #189). Гусаков зазначив, що одноразовий механізм онбордингу будівельників Glamsterdam може втручатися в шаблони захисту депозитів, на які довгий час опиралися стекінг-протоколи. За поточними правилами перший дійсний депозит для публічного ключа постійно встановлює обрані реквізити для зняття. Протоколи часто спочатку роблять невеликий депозит, перевіряють, чи з’являються очікувані реквізити, і лише потім додають залишок балансу. Під час переходу на форк спеціальний шлях онбордингу може призвести до третього результату: жоден валідатор не активується, а повний депозит зараховується будівельнику. Ядро розробників відхилило пізню зміну специфікації, яка б зберегла розрізнення між депозитами валідатора та будівельника під час одноразового онбордингу, посилаючись на те, що Sepolia вже активувався за поточними правилами, а випуски клієнта Hoodi вже готувалися. Зміна поведінки на цьому етапі вимагала б повторного розгортання Sepolia та додаткових циклів тестування.

Як посвідчення будівника 0xB0 взаємодіють із спільною чергою депозитів

Glamsterdam вводить депозити будівників у рамках переходу на закріплене розділення пропозер-будівник. Ці депозити мають облікові дані для зняття, які починаються з префікса 0xB0, що відрізняє їх від звичайних облікових даних валідатора. Під час перехідного періоду обидва типи депозитів використовують одну й ту саму чергу обробки. Оператор ноди, який контролює або може впливати на порядок подання депозитів, може таким чином вставити депозит з обліковими даними будівника, що відповідає очікуваному публічному ключу стейкера. Після прийняття першого депозиту мережа вважає публічний ключ зареєстрованим за обліковими даними будівника. Подальші депозити за тим самим ключем ігноруються для активації валідатора або перенаправляються згідно з новими правилами інтерпретації, що діють навколо межі форку.
 
Практичний ефект полягає в тому, що стейкер втрачає як очікуваного валідатора, так і депонований ETH, який тепер перебуває під контролем білдера. Існуючі активовані валідатори та вже оброблені депозити залишаються незмінними. Ризик обмежений новими або ще в черзі депозитами, які перетинають епоху активації. Оскільки поведінка спільної черги припиняється після завершення форку, а депозити білдера переходять до їхнього окремого контракту, виставлення на ризик є тимчасовим. Саме цей тимчасовий характер є основною причиною, чому Гусаков порадив не панікувати, але одночасно закликав усі сервіси делегованого стейкінгу впровадити або посилити перевірку перед депозитом до активації мейннету.

Основні розробники закрили пропозицію зі специфікацією консенсусу як незаплановану

Технічне обговорення виправлення на рівні протоколу з’явилося в питанні consensus-specs #5735. Пропозиція передбачала перевірку перед депозитом, яка б перевіряла певні умови до прийняття депозиту в чергу. Після огляду питання було закрито зі статусом «не планується». Рішення залишає відповідальність за захист на рівні застосунку, а не вбудовує додаткові перевірки в ядро протоколу. Тому публічні рекомендації Гусакова зосереджені на тому, щоб стейкінг-протоколи виконували власну перевірку перед депозитом. Часові обмеження сильно вплинули на результат. Sepolia вже зробила форк за існуючою специфікацією 6 жовтня 2026 року.
 
Випуски клієнта Hoodi наближалися до активації 26 жовтня. Внесення пізньої зміни поведінки загрожувало вимушеним повторним розгортанням Sepolia та подальшими затримками тестування. Основні розробники вважали, що обмежений час та здатність команд рівня застосунку додавати перевірки роблять патч протоколу ненецільовим на цьому етапі. Результатом є розподілена модель безпеки, в якій кожен провайдер ліквідного стейкінгу повинен підтвердити, що його канал депозитів правильно розрізняє чи блокує депозити з префіксом 0xB0, які намагаються вимагати публічні ключі валідаторів.

Переддепозитні перевірки стають основним захистом для сервісів ліквідного стейкінгу

Lido вже з ранніх часів, коли з’явилися попередні вразливості, пов’язані з депозитами, функціонує Модуль безпеки депозитів та комітет нагляду. Наглядові ради перевіряють знімки deposit-root перед тим, як пакети будуть оброблені, і один чесний наглядач може призупинити депозити. Відкритим залишається питання, чи враховує ця існуюча інфраструктура новий тип посвідчення 0xB0 та тимчасову динаміку спільної черги, чи потрібна додаткова логіка для переходу Glamsterdam. Інші протоколи, які не мають порівнянного багатоучасникового нагляду, стикаються з більш складним завданням підготовки.
 
Переддепозитні перевірки можуть мати кілька конкретних форм. Протокол може відмовляти в будь-якому депозиті, якщо дані для зняття починаються з 0xB0, коли метою є стандартна активація валідатора. Він може вимагати он-чейн або оф-чейн атестацію, що публічний ключ ще не був зареєстрований за реквізитами білдера. Він може призупинити нові депозити на короткий проміжок часу навколо епохи активації до завершення періоду спільної черги. Оскільки поверхня атаки існує лише тоді, коли черги перекриваються, тимчасове призупинення або підвищений контроль під час цього інтервалу може виключити більшість практичних ризиків. Менші або нові стейкінг-сервіси, які ще не створили комітети типу «гвардії», повинні діяти швидко, якщо планують приймати депозити під час переходу на мейннет.

Розклад активації Glamsterdam залишає мало маржі для підготовки

Фонд Ethereum підтвердив, що Glamsterdam активується на тестнеті Hoodi на епохі 132 352, слоті 4 235 264, що відповідає 26 жовтня 2026 року о 17:42:48 UTC. У ту ж епоху ліміт газу Hoodi підвищується до 200 мільйонів. Sepolia вже було активовано 6 жовтня. Час активації мейннету залишається невизначеним; обговорюються кандидатські дати на початку грудня, залежно від чистого форку Hoodi. Тому оператори нод та команди стейкінгу мають лише кілька днів після попередження Гусакова, щоб перевірити свої канали депозитів на Hoodi.
 
Клієнтські команди опублікували сумісні релізи для обох шарів: консенсусу та виконання. Оператори повинні оновити як бікон-ноди, так і клієнти валідаторів, перевірити будь-які зміни в інтерфейсах будівників, введені вбудованою відокремленістю пропозера та будівника, та підтвердити, що логіка надсилання депозитів правильно обробляє новий префікс облікових даних. Короткий інтервал між публічним попередженням та першим публічним запуском тестнету підкреслює, чому захист на рівні додатків має бути готовий до відкриття вікна переходу на мейннет.

Закріплена відокремленість пропозера та білдера вводить новий шлях депозиту

Glamsterdam поєднує зміни рівня виконання Amsterdam зі змінами рівня консенсусу Gloas. Його дві ключові функції — це вбудоване розділення пропозера та білдера (EIP-7732) та списки доступу на рівні блоку. За еPBS білдери реєструються в мережі зі своїми балансами та публічними ключами, подають пропозиції та пізніше розкривають виконавчі завантаження. Протокол самостійно обробляє оплату пропозеру, зменшуючи залежність від зовнішніх релеїв. Депозити та виходи білдерів стають першокласними виконавчими запитами, що пояснює збіг префікса облікового запису 0xB0 та тимчасової черги.
 
Дизайн покращує масштабованість, надаючи валидаторам більше часу для обробки більших обсягів даних та дозволяючи вищі ліміти газу. Водночас він створює новий шлях для підключення розробників, який слід уважно відрізняти від звичайних депозитів валидаторів. Механізми одноразового переходу є джерелом тимчасової неоднозначності. Після повного переключення мережі депозити розробників проходять через власний контракт, і ризик спільної черги зникає. Тому оновлення покращує довгострокову архітектуру, одночасно вимагаючи короткострокової уваги від будь-якого сервісу, який надсилає депозити від імені користувачів.

Попередній досвід Lido з безпекою депозитів впливає на поточну відповідь

Lido зіткнулася з рисками фронт-ранінгу депозитів у попередні роки і відреагувала, формалізувавши Модуль безпеки депозитів разом із наглядовою комісією. Комісія затверджує знімки коренів депозитів; один наглядач може ініціювати призупинення. Ця інфраструктура вже довела свою корисність у інших операційних інцидентах. Справа Glamsterdam перевіряє, чи ці ж механізми правильно виявляють новий тип облікових даних та короткий період спільного чергування.
 
Протоколи, які після раніших інцидентів прийняли подібні багатопідписові або охоронні схеми, перебувають у кращому положенні, ніж ті, що ще не впровадили порівнянні заходи безпеки. Загальна закономірність відома: оновлення протоколу можуть виявляти крайові випадки, які системи рівня застосунку повинні поглинати. Оскільки розробники ядра відмовилися від пізньої зміни специфікації, галузь повинна вважати перевірку перед депозитом обов’язковою вимогою, а не додатковою функцією. Команди, які вже моніторять корені депозитів і можуть швидко призупинити роботу, матимуть нижчий операційний ризик під час переходу.

Оператори нод та делеговані стейкери стикаються з концентрованим впливом під час вікна

Атака вимагає зловмисного або скомпрометованого оператора ноди, який може надіслати транзакцію депозиту, яка потрапить перед легітимною. Звичайні стейкери, які просто роблять депозит у протокол ліквідного стейкінгу, не можуть виконати фронт-ран; ризик лежить на операторі, який підписує або надсилає депозит у блокчейні. Існуючі активовані валідатори та вже підтверджені депозити залишаються поза межами атаки. Піддаються ризику лише публічні ключі, які мають очікуючі або недавно надіслані депозити під час епохи переходу.
 
Делеговані стейкери повинні підтвердити, що обраний ними протокол опублікував інструкції щодо обробки депозитів навколо активації Glamsterdam. Оператори повинні уважно перевірити порядок надходження, обмеження швидкості або послідовність депозитів, а також переконатися, що жоден депозит з префіксом 0xB0 не може претендувати на ключ, призначений для стандартного валідатора. Оскільки вікно коротке, тимчасове зменшення пропускної здатності нових депозитів або підвищений рівень моніторингу можуть закрити більшість практичних шляхів атаки без довготривалих порушень роботи стейкінгу.

Hoodi надає перше живе середовище для тестування процесу депозиту

Активація Hoodi 26 жовтня — це перша публічна можливість для команд стейкінгу спостерігати поведінку спільної черги в реальних умовах. Протоколи можуть надсилати тестові депозити зі звичайними та 0xB0 обліковими даними, вимірювати результати порядку та підтверджувати, що їхні фільтри перед депозитом відкидають або ізольовують небажаний шлях. Команди клієнтів вже випустили версії, сумісні з Hoodi; оператори повинні переконатися, що обидва клієнти виконання та консенсусу оновлені, а будь-яке зовнішнє інструментарій будівника було перевірено на сумісність з новими інтерфейсами.
 
Успішне тестування на Hoodi надасть галузі більше впевненості до відкриття мейннет-вікна. Невдачі або неочікувані крайні випадки, виявлені на тестнеті, все ще можна виправити за допомогою змін на рівні застосунку або коротких пауз, не вимагаючи переробки протоколу. Короткий термін між публічним попередженням та активацією Hoodi робить координоване тестування обов’язковим.

Відповідальність за зменшення ризиків тепер лежить на кожному стейкінг-протоколі

Закривши питання consensus-specs як незаплановане, основні розробники підказали, що тимчасовий ризик краще вирішувати на рівні застосунку. Постачальники ліквідного стейкінгу, платформи для самостійних операторів та будь-які сервіси, які подають депозити від імені користувачів, повинні реалізувати власні перевірки. Постачальники, які вже мають комітети-захисники або процеси атестації deposit-root, можуть розширити ці процеси, щоб охопити префікс 0xB0. Постачальники без такої інфраструктури стикаються з більш строгими термінами для додавання еквівалентних контрольних механізмів.
 
Розподілена модель має як переваги, так і недоліки. Вона дозволяє швидко та індивідуально реагувати, не чекаючи на зміну через жорсткий форк у всій мережі. Це також означає, що безпека депозиту будь-якого стейкера залежить від конкретних практик протоколу, який вони обрали. Прозорість щодо процедур обробки депозитів навколо епохи активації допоможе користувачам оцінити залишковий ризик.

Мети масштабування та тимчасові випадки залишаються пов’язаними в оновленнях ethereum

Glamsterdam просуває дорожню карту масштабування Ethereum L1, підвищуючи практичний ліміт газу до 200 мільйонів, дозволяючи паралельну обробку транзакцій за допомогою списків доступу на рівні блоків та видаляючи зовнішні релей-сервіси з критичного шляху створення блоків. Ці досягнення вимагають нових он-чей примітивів для розробників, що, в свою чергу, створюють тимчасове перекриття черги депозитів. Цей патерн є характерним для великих оновлень: довгострокові архітектурні покращення можуть викликати короткочасні крайні випадки, які команди додатків повинні керувати.
 
Здатність галузі поглинати ці крайні випадки без втрат коштів користувачів вплине на довіру до подальших оновлень. Перевірка перед депозитом, тимчасове призупинення депозитів та чітка комунікація оператора — це практичні інструменти, доступні в поточному випадку. Оскільки ризик обмежений відомим, коротким інтервалом, витрати на підготовку є обмеженими, а користь полягає у збереженні депозитів користувачів під час переходу.

Очікуючі депозити вимагають підвищеної уваги до завершення переходу

Будь-який публічний ключ, який на момент активації правил Glamsterdam має непроцесований депозит, знаходиться в межах потенційного вікна атаки. Протоколи можуть зменшити цей ризик, вичерпавши або прискоривши свої черги депозитів до епохи, відкинувши посвідчення 0xB0 для намірів валідаторів або призупинивши нові надходження на короткий період навколо активації. Безперервне моніторинг змін deposit-root та статусу клейму публічних ключів під час критичних годин дозволить швидко відреагувати у разі виявлення аномальної активності.
 
Після завершення форку та переміщення депозитів будівельників на окремий шлях контракту, спільний вектор черги закривається. Тому навантаження на моніторинг має чітку дату завершення. Команди, які сприймають перехід як період з підвищеною увагою, а не як звичайне оновлення, будуть найкраще підготовлені для захисту коштів стейкерів.

🔥 Поза заголовками: що означає KuCoin 5.0 для вас

Новини ринку рухаються швидко — але те, де ви дієте з ними, має рівно таке ж значення. Цього жовтня KuCoin запускає KuCoin 5.0, перетворюючи KuCoin на відновлену платформу. Ось що змінюється саме для вас:
 
  • Один акаунт для всього. Старі платформи розділяли ваші кошти між окремими акаунтами «спот», «маржа» та «ф'ючерси» і очікували, що ви зрозумієте чому. Єдиний акаунт KuCoin 5.0 повністю видаляє це — зробіть депозит один раз, і все буде просто там (наразі доступно лише для VIP).
  • Акції, індекси та товари. KuCoin 5.0 розширюється за межі криптовалют на глобальні ринки. Коли криптовалюти рухаються бічно, а акції ростуть (або навпаки), ви переключаєтеся за хвилини, замість того щоб відкривати брокерський акаунт і чекати днів на фіатні канали.
  • Реальні активи (RWA). Токенізований доступ до традиційних активів, таких як сировина, прямо в вашому крипто-акаунті. Один із найшвидше розрастаючих сегментів у світовій фінансовій сфері більше не є виключною привілеєю інституцій — ви отримуєте до нього доступ з того ж балансу, з яким торгуете.
  • Заробляйте, поки вчитеся. Ще не готові торгувати? KCUSD дозволяє вашим стейблкоїнам заробляти щоденні автокомпаунд-відсотки. Найменш стресовий спосіб використати ваші неактивні депозити для отримання 4% дохідності.
  • AI-асистент простою мовою. Задавайте питання, отримуйте контекст ринку, розумійте, що ви бачите — інтегровано в платформу, без жаргону.
  • Додаток, який не перевантажує. Швидший, чистіший і послідовний — інтуїтивний з першого дотику, а не після навчання.
  • Безпека, яку можна перевірити, а не просто вірити. Організація з ліцензією MiCAR у ЄС, Proof of Reserves, який ви можете перевірити самостійно, та міжнародно сертифікована безпека (SOC 2 Type II, ISO 27001:2022).
 
Створіть акаунт за хвилини — і почніть працювати на платформі, створеній для майбутнього криптовалют, а не минулого.

ЧАСТІ ПИТАННЯ

Що саме таке оновлення Glamsterdam і чому воно має значення для стейкінгу?

Glamsterdam — це об’єднана назва змін рівня виконання Amsterdam та консенсусного рівня Gloas. Їхніми основними цілями є закріплене розділення пропозера та будівельника та списки доступу на рівні блоків, які підтримують вищі ліміти газу та більш ефективну обробку блоків. Для стейкінгу введення реєстрації будівельників у мережі та пов’язаний шлях депозиту створює тимчасову поведінку спільного чергування, що лежить в основі ризику фронт-ранінгу.
 

Як довго триває вікно захоплення депозиту?

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

Чи впливає ризик на вже активовані валідатори чи існуючі зарезервовані ETH?

Ні. Атака спрямована на нові або ще в черзі депозити для публічних ключів, які ще не створили активного валідатора. Існуючі валідатори та їх баланси залишаються під своїми встановленими реквізитами для виведення і знаходяться поза описаним вектором атаки.
 

Що можуть зробити звичайні стейкери, щоб захистити себе?

Стейкери, які здійснюють депозит через протокол рідкісного стейкінгу, повинні переконатися, що протокол опублікував конкретні рекомендації щодо обробки депозитів навколо активації Glamsterdam. Вибір провайдера, який вже використовує багатоузову безпеку депозиту або нагляд у стилі «опікуна», зменшує залишковий ризик. Стейкери, які запускають власні валідатори, повинні переконатися, що їхня логіка надсилання депозиту не дозволяє конкуруючому депозиту 0xB0 клеймити той самий публічний ключ.
 

Чому розробники ядра відмовилися від виправлення на рівні протоколу?

Пропозицію щодо перевірок перед депозитом закрито як незаплановану, головним чином через тиск термінів. Sepolia вже було активовано за існуючими правилами, а випуски клієнта Hoodi продовжувалися. Пізні зміни поведінки могли б призвести до додаткових перерозгортань тестнету та затримок. Розробники вважали, що засоби зменшення ризиків на рівні застосунку є достатніми враховуючи обмежений термін експозиції.
 
Відмова від відповідальності: Цей матеріал надано виключно в інформаційних цілях і не є інвестиційною порадою. Інвестиції в криптовалюту супроводжуються ризиками. Будь ласка, проводьте власне дослідження (DYOR).
 

Відмова від відповідальності: Для вашої зручності цю сторінку було перекладено за допомогою технології ШІ. Для отримання найточнішої інформації дивіться оригінальну англійську версію.