Чому non-custodial стейкінг дає збої під час виведення
Класичний сценарій: валідатор зібрано, активи розміщено в non-custodial стейкінгу, нагороди нараховуються місяцями.
А в момент, коли потрібно вивести кошти або вийти з валідатора, підпис поставити нікому: ключі та ролі підпису зведено в одну точку — одна машина, один каталог із ключами, один адміністратор із доступом до нього.
Мережа Ethereum та інші мережі з роздільними ключами підпису й виведення потребують їх формального розведення. На практиці ключ атестацій, ключ виходу та ключ виведення лежать в одному сховищі й відкриваються одним обліковим записом. Поки склад команди не змінюється, схема працює без зауважень.
Ламається вона на ротації зміни, відкликанні доступу у зовнішнього інженера або втраті доступу до сховища: єдина точка відмови підпису перетворюється на блокування виведення активів.
При цьому самі активи обліковуються на балансі й виглядають доступними — рівно до першої спроби вийти з валідатора.
Ціна поломки — не лише простій. Валідатор продовжує отримувати штрафи за пропущені атестації, а відновлення йде через розбір логів, збирання ключів із резервних копій і повторну синхронізацію. Ризик чужого зберігання проявляється не як крадіжка, а як неможливість розпорядитися своїм.
Розбираємо, як це закривається: ролі підпису розносяться по різних контурах, доступ видається пороговий, а вихід із валідатора виноситься в окремий регламент із перевіркою на тестовій мережі.
Що змінюється після розділення ключів і активів
Після розділення ключів і активів змінюється не лише модель доступу, а й набір вимірюваних параметрів, за якими перевіряють якість впровадження.
Ключ підпису залишається в держателя, а облік активів ведеться окремо — сервіс не може розпорядитися коштами, навіть якщо його інфраструктуру скомпрометовано повністю.
Це перший пункт перевірки: якщо технічна можливість підписати виведення без власника зберігається, розділення не виконано.
Далі — ролі підпису. Повсякденні операції, виведення нагороди та ребалансування закриває гарячий ключ з обмеженою політикою, а зміна набору валідаторів, параметрів або адрес отримувача потребує холодного ключа й кворуму.
Порогова схема розносить частки між незалежними зберігачами, тому одна скомпрометована машина підпису не дає.
Третій пункт — час відновлення доступу. Резервні частки зберігаються в різних сторін і збираються за описаною процедурою: відновлення займає десятки хвилин і не залежить від працездатності одного вузла або листування з підтримкою. Перевіряється репетицією — до того, як це знадобиться в аварії.
Нарешті, який клас відмов зникає. Зникає цілий пласт: заморожування виведення, відмова в підписі, недоступність зберігача активів, спір про те, хто власник коштів. Залишаються тільки відмови, пов’язані з власними ключами та логікою контракту, — вузький і передбачуваний набір.
Виведення перестає бути ручною операцією: заявка йде відомим маршрутом, а вікно виведення вимірюється хвилинами й не залежить від чужого графіка.
Формати non-custodial стейкінгу та їхні обмеження
Non-custodial стейкінг — це передусім про те, у кого залишаються ключі, а не про те, хто експлуатує обладнання. Навіть при делегуванні активи не переходять на баланс сервісу: виведення ініціює лише власник.
Але право розпоряджатися часткою й контроль над її працездатністю — різні речі, і далі починається розвилка: хто тримає вузол у мережі, хто відповідає за його доступність і що відбувається з часткою при збої або штрафному списанні.
Порівнювати формати варто за трьома осями — де зберігаються ключі, хто відповідає за працездатність вузла й наскільки глибоко ви керуєте його параметрами. Нижче — альтернативи, між якими реально обирають на старті.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Пул валідаторів | Потрібно увійти швидко, без власної інфраструктури, ключі залишаються у власника | Ви не впливаєте на комісію пулу, склад валідаторів і графік їхніх оновлень; поріг входу мінімальний, керованість — теж |
| Оператор вузла | Власне обладнання не потрібне, але потрібні виділені параметри й звітність | Залежність від одного оператора: його простій або зміна політики безпосередньо зачіпають вашу частку |
| Власний валідатор | Обсяг активу й вимоги до контролю виправдовують експлуатацію | Повний поріг входу: сервери, резервування, моніторинг, оновлення, чергування, ризик штрафного списання за пропуски |
Поріг входу — головний розділювач між цими форматами. Власний валідатор означає цілодобове чергування, другий вузол під холодний резерв і відпрацьовану процедуру оновлення без пропуску раундів голосування.
Пул знімає експлуатацію повністю, але разом із нею зникає й вплив на параметри. Оператор вузла — компроміс, де частина відповідальності залишається на підряднику.
Обмеження архітектури важливіші за дохідність: чим менше проміжних шарів, тим нижчий ризик втратити доступ до активу, але тим вища інженерна навантаженість. Розбираємо, як підібрати цей баланс під ваш сценарій.
Етапи впровадження: від аудиту ключів до передачі регламентів
Non-custodial стейкінг ламається не на математиці, а на організації доступу до ключів.
Ми ведемо впровадження як послідовність перевірюваних кроків: спочатку фіксуємо, як влаштоване володіння зараз, потім проєктуємо схему підпису під модель загроз замовника і тільки потім пишемо код. Кожен етап закривається артефактом, який можна перевірити до переходу до наступного.
- Аудит ключів. Інвентаризуємо всі ключі та частки: де згенеровані, де зберігаються, хто отримує до них доступ, чи є копії поза контуром. На виході — карта володіння та список розбіжностей між заявленою і фактичною моделлю.
- Схема підпису. Обираємо порогову конфігурацію: скільки часток потрібно для операції та як вони розподілені між сторонами. Один скомпрометований учасник або вузол не може вивести кошти самостійно.
- Налаштування ролей. Розділяємо ініціатора операції, підписувачів і спостерігача, задаємо ліміти та часові вікна. Дії потрапляють до незмінного журналу — спірні ситуації розбираються за фактами, а не за листуванням.
- Перевірка виведення. Проганяємо сценарії на малих сумах: штатне виведення, виведення при недоступності частини підписувачів, спроба операції поза лімітом. Переконуємося, що відкат не залишає кошти в підвішеному стані.
- Спостереження за вузлами. Піднімаємо контроль валідаторів і делегування: пропущені блоки, падіння дохідності, розбіжність балансів. Оповіщення надходять раніше, ніж проблема стає збитком.
- Передача регламентів. Віддаємо документацію: порядок видачі часток, ротація, дії при інциденті, зони відповідальності. Навчаємо команду замовника на тестовому контурі.
Що залишається у вас: конфігурації, схеми, політики, регламенти
Розробка non-custodial стейкінгу закінчується не демо-запуском, а папкою артефактів у вашому контурі.
Ми віддаємо не «чорну скриньку», а опис системи в тому вигляді, у якому її зможе супроводжувати ваш інженер або інший підрядник: схеми, політики, ролі, регламенти й процедури відновлення.
- Схеми взаємодії компонентів — хто з ким обмінюється даними, де проходять межі довіри, як влаштовано шлях операції від ініціації до підтвердження в мережі.
- Політики доступу — які сховища ключів використовуються, хто і через який інтерфейс ініціює дії, як видається і як відкликається доступ.
- Матриця ролей — таблиця «операція × роль»: що допустимо одному черговому, що потребує другого підпису, хто власник рішення.
- Конфігурації у версіонованому вигляді — параметри вузла, правила моніторингу, шаблони розгортання: середовище піднімається відтворювано, а не «за пам’яттю інженера».
- Регламенти реагування — пропуск атестації, падіння вузла, розбіжність із мережею, компрометація оператора: порядок дій, зона відповідальності, цільовий час реакції.
- Документація та журнал змін — інструкція з розгортання з нуля, пам’ятка чергового, процедура виведення коштів і виходу з валідації без участі підрядника.
- Чек-ліст приймання — включно з тестовим відновленням на чистому середовищі: поки ваш інженер не підняв систему сам, передача не вважається завершеною.
Кейс: розділення ролей підпису та виведення активів без посередника
Клієнт — оператор валідаторів, який піднімав non-custodial стейкінг для кількох десятків гаманців.
Ключ підпису й ключ виведення лежали в одному сховищі під однією роллю, тому будь-яка операція з активами йшла через посередника, а інженер із доступом до підпису технічно міг ініціювати виведення. Ось що показали метрики до та після розділення ролей у мережі Ethereum.
Метрики до впровадження
Виведення активів займало від двох до трьох діб: заявка йшла до посередника, підтвердження чекали вручну, частина операцій зависала до наступного робочого дня.
За квартал фіксували 5-6 інцидентів підпису — від повторного підпису одного й того самого набору даних до спроби виведення з адреси, до якої доступу бути не повинно. Відновлення доступу після зміни інженера розтягувалося на дні й залежало від того, чи відповість посередник.
Що змінили і що стало
Розвели контури: ключ підпису залишився на валідаторі в закритому сегменті, ключ виведення переїхав до окремого сховища з пороговою схемою 2 з 3 — частки в різних держателів, зібрати підпис на виведення можна лише спільно.
Тепер виведення активів займає 15-25 хвилин без посередника й ручних підтверджень, а інцидентів підпису за зіставний період не залишилося: кожен набір даних проходить журнал із прив’язкою до ролі й операції та відхиляється до підпису, якщо не збігся із шаблоном.
Ротація ключа підпису більше не зачіпає контур виведення — скомпрометований ключ змінюється за годину, кошти залишаються у власника. Відновлення доступу вкладено в регламент на годину, тому що частки зберігаються в різних людей і не залежать від однієї людини.
Чим відрізняється роздільне зберігання ключів від мультипідпису?
Роздільне зберігання відповідає на питання, хто вправі розпоряджатися коштами, а пороговий підпис — скільки зберігачів потрібно, щоб підпис відбувся. У першій моделі в кожного учасника свій ключ повністю, і правило перевіряється за фіксованим списком підписувачів.
У другій ключ розкладено на частки: для підпису достатньо порогового їх числа, і жоден вузол не бачить ключ повністю.
Мультипідпис прозорий: список підписувачів і поріг лежать у відкритому стані, операцію можна розібрати заднім числом і побачити, чий голос її блокує.
Обмеження — ключ зберігається повністю у власника, тому компрометація однієї машини дає дії від імені легітимного учасника: поріг захищає казну, але не сам голос. Обсяг обчислень на перевірку підписів при цьому зростає з числом підписувачів.
Порогові підписи знімають обидва обмеження: частка не дозволяє підписати самостійно, ключ не збирається в жодному процесі, а до мережі йде один компактний підпис незалежно від числа часток.
Частки розкладають по апаратних модулях підпису в різних юросіб і в різних контурах — модуль віддає лише результат обчислення, витягти частку з нього не можна.
Межа проходить за зонами відповідальності. Питання про те, хто відповідає за операцію і як це підтверджується для аудиту, вирішують роздільним зберіганням і мультипідписом із явним списком. Питання про усунення єдиної точки відмови — пороговою схемою.
На практиці їх поєднують: частки в апаратних модулях різних організацій плюс контракт, що фіксує ліміти й зони відповідальності.
Часті технічні питання щодо впровадження схеми підпису
Перш ніж погодити план робіт, інженерні команди задають один і той самий набір питань: де живе ключ підпису, що станеться з активами при відмові вузла і чи можна перевести вже розміщені кошти без виходу з активації. Нижче — короткі відповіді; детальний розбір із конфігураціями йде на етапі проєктування.
Хто отримує доступ до ключа підпису?
Ключ генерується на стороні замовника і ніколи не збирається повністю: частки розподіляються між учасниками за пороговою схемою, підпис формується лише за згоди заданого числа держателів.
Наша команда налаштовує процедуру й аудит, але не отримує можливості одноосібно розпорядитися коштами або підмінити адресу виведення.
Що буде, якщо оператор вузла відмовить?
Зміна підпису й плановий вихід з активації виконуються окремими ключами, які залишаються у замовника.
Відмова обладнання призводить до пропуску обов’язків і штрафу мережі, але не до втрати активів: вузол піднімається зі збереженого стану, а при тривалому простої актив виводиться і повертається в роботу без поспіху.
Як перенести вже розміщені активи?
Якщо поточна схема допускає зміну адреси розпорядження, переводимо управління на нову адресу, зібрану за пороговою схемою, — активи продовжують працювати, повного виведення не потрібно.
Коли управління жорстко прив’язане до кастодіана, плануємо цикл виходу й повторного розміщення з вікном простою, у яке нагороди не нараховуються.
Ці сумніви закриваються до першого запуску — на них будується план міграції активів і розділення відповідальності між сторонами.Обговоримо вашу схему зберігання ключів і ролей підпису
Оцінка такої задачі не рахується «на око» — вона розгортається з вашої поточної схеми.
Тому починаємо з розбору: де зберігаються ключі валідатора, хто ініціює підпис, як розділені ролі оператора й власника коштів, що відбувається при виведенні зі стейкінгу і наскільки пороги підпису (наприклад, 2 з 3) відповідають вашому профілю ризику. За підсумками розбору повертаємося з оцінкою, планом робіт і порядком передачі в експлуатацію.
Що у вас залишається на руках після цього етапу:
- Розбір поточної схеми зберігання ключів і підпису: гарячий і холодний контури, хто має доступ, де єдина точка відмови.
- Оцінка схеми та ролей підпису: які ролі потрібні під ваш профіль ризику, де їх варто розділити, а де поточний устрій надлишковий.
- План впровадження за етапами із залежностями між ними — що можна викочувати частинами, не зупиняючи чинних валідаторів.
- Порядок робіт і зони відповідальності: що закриваємо ми, що залишається на вашій стороні і в які строки.
- Порядок передачі в експлуатацію: регламенти підпису й ротації, процедура відновлення доступу, приймання й навчання вашої команди.
- Перелік вхідних для старту: схема ролей, доступи до контурів, відповідальні за підпис з боку замовника.
Щоб повернутися з оцінкою, а не із загальними словами, опишіть задачу: скільки валідаторів, як зараз зберігаються ключі, які ролі підпису вже заведені. Цього достатньо, щоб зібрати план робіт і порядок передачі в експлуатацію.
