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