MetaMask виходить із валідаторів. Куди далі подінеться застейканий ETH?

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

Розкриття вказує на вихід, а не на злом гаманця

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

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

Компанія запустила Validator Staking через MetaMask Portfolio як домовленість, за якої клієнти надають стейк, а постачальник керує вузлами валідаторів. Попередній опис продукту є корисним контекстом, хоча він не може сказати нам, якого поточного продукту або групи клієнтів стосується вересневий інцидент. Відтоді MetaMask відокремила свою корпоративну ідентичність від Consensys, ще одна причина не зводити кілька брендів, операторських суб’єктів і продуктів стейкінгу в єдиний постраждалий пул без нового розкриття.

Першим помітним виправленням публічного запису буде заява про масштаб. Повідомлення про інцидент — це позначений часом звіт про те, що компанія знає, а не повний криміналістичний звіт. Якщо MetaMask згодом розкриє постраждалий набір ключів, відповідні облікові дані клієнтів для виведення коштів і те, чи був якийсь валідатор підданий слешингу або пропустив обов’язки, аналіз зможе стати конкретним. До того часу обґрунтований опис є вужчим: запобіжні виходи тривають, а кількість залучених ETH невідома.

Валідатор може припинити підписування, а клієнт не отримає ETH

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

Документація Ethereum щодо виведення коштів розрізняє застарілий валідатор з ефективним балансом 32 ETH і валідатор із компаундуванням, ефективний баланс якого може зростати до 2 048 ETH. Останнє змінює наївний розрахунок, що один валідатор завжди означає рівно 32 ETH. Публічне повідомлення MetaMask не вказує, які облікові дані або типи валідаторів постраждали. Множення приблизної кількості валідаторів на 32 створило б оцінку, яка виглядає точною, але не має обох вхідних даних.

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

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

Ключовий поділ визначає межу безпеки

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

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

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

Технічне розділення має економічний наслідок. Клієнт може зберегти ETH, але втратити частину очікуваних винагород під час переходу. Валідатор, який більше не отримує винагород, перебуваючи поза активною службою, не може надолужити цей час, стверджуючи, що початковий стейк був у безпеці. Безпека основної суми та безперервність дохідності — це різні сервісні обіцянки. Нещодавня робота Lido з консолідації ще більше ускладнює будь-який простий показник кількості ключів: тип облікових даних і ефективний баланс впливають на те, яку частку стейку представляє один валідатор.

Публічні цифри не підтверджують загальний обсяг exposure

Поширений розрахунок — це кількість уражених валідаторів, помножена на 32 ETH. Єдина цифра, наведена в заяві про інцидент, — жодної: MetaMask не повідомила, скільки валідаторів вона виводить. Ethereum тепер також дозволяє компаундування валідаторів понад 32 ETH. Отже, в арифметиці бракує двох членів, а не одного. Якби гіпотетичні 100 застарілих валідаторів були уражені, їхній початковий ефективний стейк становив би 3 200 ETH. Цей приклад є перетворенням одиниць, а не твердженням про цей інцидент. Було б неправильно ставити 3 200 ETH у заголовок без фактичної кількості валідаторів.

Ще один спокусливий короткий шлях — подивитися на сукупну чергу виходу мережі. Це загальномережевий підсумок, а не список клієнтів MetaMask. Інші установи, стейкінгові пули та соло-оператори можуть входити в чергу або виходити з неї того самого дня. Зростання черги після розкриття інформації встановило б одночасний попит на вихід, а не приналежність до MetaMask. Індивідуальні індекси валідаторів, прив’язані до оператора, разом із опублікованою заявою про сферу застосування, могли б звузити оцінку. Панель, яка групує лише за графіті або джерелом депозиту, може неправильно класифікувати клієнтів, об’єднаний стейк або пізніше перепризначення.

Раніше розстейкінг Ethereum Foundation показує, як помітне велике виведення може привернути ринкову історію, перш ніж стане зрозумілою мета гаманця-отримувача. Подія MetaMask є більш непрозорою. Жоден поточний публічний баланс інциденту не може бути перевірений із короткого повідомлення компанії. Читачам слід скептично ставитися до цифри ETH, що циркулює, якщо її автор не надасть відтворюваний список індексів валідаторів, типів облікових даних і адрес виведення, а також метод виключення не пов’язаних валідаторів.

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

Пропускна здатність виходу належить мережі, а не постачальнику

Ethereum обмежує, як швидко валідатори можуть вийти. Черга виходу не є довільним утриманням, накладеним MetaMask; це протокольний механізм, який розподіляє виходи в часі. Її довжина залежить від того, скільки валідаторів по всьому Ethereum намагаються вийти, активного набору валідаторів мережі та застосовних лімітів відтоку. Після виходу право на виведення та переказ на облікові дані для виведення додають кроків. Посібник із виведення стейкінгу попереджає користувачів об’єднаного стейкінгу перевіряти зі своїм постачальником, оскільки продукти обробляють шлях по-різному.

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

Вартість не є фіксованим відсотком. Простий приклад альтернативної вартості показує чутливість: 32 ETH за припущеної річної валової ставки 3% генерують близько 0,00263 ETH за один день, або приблизно 0,0395 ETH за 15 днів. Це арифметика, а не прогноз для поточних доходностей або клієнтів MetaMask. Тип валідатора, домовленості про комісії, пропущені атестації, винагороди рівня виконання та тривалість поза активною службою — усе це змінює фактичний результат. Суть у тому, що час між ефективним виходом і новою активацією має значення, навіть коли основна сума 32 ETH залишається недоторканою.

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

Запобіжний вихід — дорога, але виправдана відповідь

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

Клієнт все ще може обґрунтовано запитати, чому вихід був необхідний, якщо жодному гаманцю не загрожували. Відповідь полягає в різних доменах безпеки. Доступ до гаманця та робота валідатора — це різні сервіси. Формулювання MetaMask не розкриває компонент інфраструктури та не доводить, чи торкнувся атакуючий будь-якого з них. Запобіжний захід може виявитися ширшим, ніж потрібно; криміналістичний звіт може пізніше це прояснити. Можна прийняти швидкий захисний вихід як розважливий, водночас наполягаючи на точному звіті про його вартість і масштаб.

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

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

Клієнтам потрібно зіставити власний контракт, а не лише ланцюг

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

Почніть із записів про депозит. Публічний ключ валідатора та облікові дані для виведення можна порівняти з тим, що показував продукт під час онбордингу. Клієнт не повинен вставляти seed-фразу у форму для повідомлення про інцидент або приймати повідомлення про те, що передача аварійного ключа є обов'язковою. Розкриття MetaMask не оголошує про міграцію гаманця. Офіційні канали продукту та незалежно введені URL-адреси мають особливе значення, коли інцидент безпеки створює можливість для імітаторів.

Далі розрізняйте три поля статусу: очікування виходу, вийшов і виведено. Очікування виходу означає, що валідатор залишається в черзі й може все ще мати обов'язки. Вийшов означає, що він більше не бере участі у звичайних обов'язках консенсусу. Виведено означає, що баланс фактично досяг свого призначення. Внутрішня панель оператора може використовувати «завершено» для власного адміністративного кроку, тому клієнту слід запитати відповідний індекс валідатора та докази транзакції або епохи. Час, коли винагороди припиняються, не обов'язково є часом, коли користувач бачить ETH у гаманці.

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

Реєстр втрат має чотири окремі колонки

Остаточний облік має розрізняти основну суму, штрафи протоколу, невиплачені винагороди та сервісні збори. Їх часто зводять до однієї заяви про те, що клієнти були або «в безпеці», або «постраждали». Основна сума — це баланс, який зрештою надходить на облікові дані для виведення, за вирахуванням змін протоколу до балансу валідатора. Штрафи — це списання, спричинені пропущеними обов'язками або доведеною неправомірною поведінкою, поки валідатор залишається активним. Невиплачені винагороди є контрфактичними: те, що рівноцінно розташований активний валідатор міг би заробити протягом цього проміжку. Сервісні збори залежать від контракту й можуть накопичуватися або не накопичуватися, поки жоден валідатор не активний.

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

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

Об'єднані продукти додають ще один рівень. Окремий власник може бачити баланс токенів або обмінний курс, тоді як пул обертає базові валідатори. Для такого клієнта відповідна звірка включає зобов'язання пулу, вимоги на погашення та частку будь-яких збитків, які несуть оператори, страхові фонди або власники. Один квитанція валідатора в ланцюжку не може встановити результат для власника. Інтеграція кастодіального обслуговування Lido від Anchorage ілюструє, чому сторона, яка утримує рахунок, оператор, який підписує, і протокол, який обліковує об'єднані вимоги, можуть усі відрізнятися. Повідомлення від 30 вересня не вказує, яка домовленість застосовується до кожного постраждалого клієнта.

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

Ринковий сигнал слабший за операційний сигнал

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

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

Межі поточного запису разючі. Немає розкритих втрат, немає підтвердженого шляху атакувальника, немає опублікованого списку валідаторів і немає перевіреної загальної частки в повідомленні MetaMask станом на 1 жовтня. Компанія може звузити або розширити сферу. Спостерігач ланцюжка може незалежно ідентифікувати деякі виходи, але приписування кожного з них інциденту вимагає підтвердження. Стаття, яка представляє точний потік ETH сьогодні, заповнювала б ці прогалини припущеннями.

Відповідь на заголовок, таким чином, умовна, але корисна. Застейканий ETH залишається прив'язаним до кожного валідатора, поки протокол не випустить його до призначеного місця виведення цього валідатора. MetaMask каже, що клієнти, а не MetaMask, контролюють ключі виведення. Що відбувається після отримання, залежить від клієнта та продукту. Операційний вихід триває. Кінцеве призначення коштів — це окреме рішення, яке ще належить спостерігати.

Що незалежний аудит міг би фактично перевірити

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

Друга перевірка — порядок подій. Чи кожен постраждалий валідатор припинив підписувати до того, як його вихід набув чинності? Чи було будь-яке порушення, що підлягає скороченню, або вимірюваний період пропущених обов'язків? Транзакція виходу або підписане повідомлення про вихід самі по собі не можуть відповісти на перше питання; валідатор може залишатися активним, перебуваючи в черзі. Публічні записи ланцюжка маяків можуть показати атестації, пропозиції, епохи виходу та виведення для відомих індексів валідаторів. Вони не можуть розкрити, який сервер був скомпрометований або до чого мав доступ атакувальник. Судово-медичне твердження про першопричину вимагало б журналів, записів доступу та незалежного тестування постраждалої інфраструктури.

Четверта перевірка — хто заплатив за переривання. Постачальник може зарахувати клієнтам кошти за простій, скасувати комісію або вказати на умови, за якими змінні винагороди мережі ніколи не гарантувалися. Жоден з цих результатів не випливає з успішного виведення. Для виділених валідаторів аудит може вказати реалізовані винагороди та штрафи за пропущені обов'язки для кожної когорти. Для пулу він повинен узгодити облік часток і будь-яке страхування або операторську облігацію, використану для поглинання збитків. Єдиний відсоток дохідності в заголовку приховав би обидва.

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

На що звернути увагу

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

Часті запитання