Restaking позволяет использовать экономическую безопасность одного набора активов для дополнительных сервисов. Оператор регистрируется в operator sets, запускает программное обеспечение и принимает правила штрафов. Если обязательство нарушено, часть выделенного stake может быть сокращена. Риск становится коррелированным, когда одна техническая или организационная причина создаёт нарушения сразу в нескольких сервисах.
Корреляция не обязательно означает, что один и тот же токен одновременно обещан всем. Современная модель EigenLayer разделяет выделения через Unique Stake. Однако один оператор способен потерять несколько отдельных выделений, если общий ключ, клиент или инфраструктура подводят все связанные процессы одновременно.
Как slashing связан с operator set
В EigenLayer operator set определяется адресом AVS и идентификатором набора. Оператор добровольно регистрируется в нём и выделяет долю доступного stake по выбранным стратегиям. AVS заранее задаёт, какие стратегии принимаются, какие обязанности выполняют операторы и при каком нарушении применяется штраф.
Контракт AllocationManager учитывает регистрации, выделения и slashable magnitude. Авторизованный slasher конкретного operator set может указать стратегии и долю, которую требуется сократить. Протокол проверяет полномочия и доступную величину, но смысловое доказательство вины зависит от правил самого AVS. Значит, безопасность включает не только код EigenLayer, но и критерии, наблюдателей, governance и ключ slasher каждого сервиса.
Штраф в учёте magnitude необратим после выполнения. В актуальной контрактной архитектуре может существовать отдельная задержка перед окончательным сжиганием или перераспределением соответствующих shares, но это не следует воспринимать как универсальную апелляцию, которая автоматически отменит ошибочное решение.
Что изменяет Unique Stake
Unique Stake не позволяет одной единице magnitude выбранной стратегии одновременно быть выделенной более чем одному operator set. Сумма активных allocations ограничена общей magnitude оператора. Для AVS это создаёт понятный объём залога, который не исчезнет из-за штрафа другого набора.
Такая изоляция устраняет простую схему «один и тот же доллар обеспечивает всё сразу». Если набор A штрафует своё выделение, он не должен отнять уникальную долю, зарезервированную за набором B. Архитектура делает границы экономического залога явными.
Но портфель делегатора всё равно может включать несколько уникальных долей одного оператора. Если оператор получил нарушения в A, B и C, каждый набор независимо сократит собственное выделение. В результате один общий сбой приведёт к нескольким штрафам, хотя ни один токен не был задвоен.
Откуда возникает коррелированная ошибка
Самый очевидный источник – общий signing key. Если несколько сервисов используют один ключ или одинаково уязвимую систему его хранения, компрометация позволяет сформировать некорректные подписи сразу для нескольких задач. Разные operator sets не спасают от общей операционной точки отказа.
Вторая причина – единый программный стек. Одинаковая версия клиента, библиотека агрегации подписей или ошибочная конфигурация может выдавать неверный результат всем AVS, которые используют этот компонент. Формально обязанности разные, но дефект распространяется по общему коду.
Третья причина – инфраструктура. Один облачный регион, поставщик RPC, база данных, система времени или конвейер обновления способны одновременно остановить множество процессов. Если AVS штрафует за liveness, длительный простой затрагивает все сервисы с совпадающим окном обязанности.
Наконец, корреляция появляется на уровне управления. Одна команда контролирует несколько slasher keys, использует общий multisig или получает данные от одного oracle. Ошибка наблюдателя либо компрометация governance тогда превращается в серию формально независимых решений.
Почему выход не мгновенно убирает риск
Оператор не может увидеть проблему и моментально обнулить slashable stake. При deregistration и deallocation действуют задержки. В EigenLayer после выхода из operator set сохраняется период, в течение которого старые обязанности ещё могут быть наказаны. Это защищает AVS от ухода оператора сразу после нарушения.
Делегатор также сталкивается с очередью вывода и состоянием allocations. Запрос на withdrawal не обязательно мгновенно освобождает активы от уже возникшей ответственности. Нужно понимать, на каком блоке прекращается slashability и какие правила применяются к операциям, совершённым до выхода.
В обзоре EigenLayer отдельно разобраны роли staker, operator и AVS. Это важно: делегатор не выполняет задачу лично, но принимает экономический результат выбора оператора и его наборов.
Как оценить общую точку отказа
Начните не с рекламной доходности, а с карты зависимостей. Для каждого operator set запишите AVS, принятые стратегии, выделенную magnitude, адрес slasher, критерий нарушения и получателя перераспределённого stake. Затем отметьте, какие наборы обслуживает один оператор.
У оператора стоит выяснить, разделены ли ключи, процессы и инфраструктура. Полезны разные signing domains, изолированные key managers, независимые узлы, резервные RPC, разные регионы и поэтапные обновления. Само заявление о резервировании ничего не доказывает, если мониторинг, секреты и деплой остаются общими.
Проверьте концентрацию делегации. Даже хорошо разделённые allocations несут общий риск, если значительная часть позиции направлена одному оператору. Диверсификация по операторам помогает только тогда, когда они не используют одну и ту же команду, облако, клиент и управляющие ключи.
Наконец, изучите правила каждого AVS: что считается доказательством, кто инициирует slashing, есть ли задержка, публичное оспаривание или аварийная пауза. Административные роли нужно проверять onchain, как и владельцев multisig и порог подписей. Отдельно найдите механизмы, описанные в инструкции по проверке timelock и pause.
Пример с тремя сервисами
Представим оператора, который выделил разные доли stake трём наборам. Первый проверяет доступность данных, второй агрегирует подписи, третий подтверждает результат вычисления. Экономически доли разделены Unique Stake, поэтому каждый сервис рассчитывает на свой залог.
Оператор разворачивает все процессы через один pipeline. Ошибочное обновление меняет библиотеку подписи и одновременно останавливает резервный мониторинг. Первый сервис фиксирует недоступность, второй получает неверную подпись, третий пропускает обязанность. Каждый AVS применяет собственный критерий и штрафует только свою долю, но общий ущерб для делегатора складывается из трёх событий.
Если бы те же наборы обслуживали независимые ключи, версии клиента и регионы, одна ошибка не обязательно распространилась бы дальше. Именно поэтому номинальное число AVS не показывает диверсификацию – важна независимость их реального исполнения.
Чек-лист для делегатора
- какие operator sets обслуживает выбранный оператор;
- сколько stake выделено каждому набору и по каким стратегиям;
- кто контролирует slasher и как формируется доказательство нарушения;
- разделены ли ключи, клиенты, облачные регионы и конвейеры обновления;
- каковы deallocation, deregistration и withdrawal delays;
- куда направляется сокращённый stake и когда решение становится окончательным;
- не повторяются ли те же инфраструктурные зависимости у других операторов.
Restaking превращает техническую надёжность оператора в экономический риск делегатора. Unique Stake делает залог сервисов раздельным, но не разделяет людей, ключи и серверы автоматически. Поэтому оценка должна охватывать две карты одновременно: onchain allocations и реальные общие точки отказа.
