Разработка протокола restaking на EigenLayer под ключ

Разработка restaking протокола: где рвётся механика

Типовой протокол повторного стейкинга уверенно проходит первые дни и начинает расходиться с сетью через две-три недели. Дело не в нагрузке, а в учёте доли: она зафиксирована на момент депозита, тогда как оператор меняет набор сервисов и частично выводит средства. У решений поверх EigenLayer механика та же — меняется только источник подтверждений.

Сбои выплат накапливаются каскадом. Награда считается по старому снимку доли, часть подтверждений приходит с задержкой, округления при пересчёте уводят баланс на доли процента. Сначала расхождение маскируют ручными доначислениями — поэтому оно всплывает уже в основной сети.

Архитектура протокола должна разводить три независимых слоя: учёт доли, распределение награды между операторами и сервисами, жизненный цикл оператора с окнами входа и выхода. Когда всё это живёт в одном контракте, смена набора сервисов тянет за собой пересчёт выплат, а откат требует остановки протокола.

Отдельный источник отказов — неидемпотентная обработка событий: повтор рождает двойное начисление, пропуск — недоплату, которая не видна без сверки с состоянием сети. Мы ведём журнал событий и сверку перед фиксацией, чтобы расхождение выявлялось до выплаты, а не после обращения пользователя.

Разработка restaking протокола, которая это выдерживает, отличается не языком контрактов, а моделью учёта и границами отказа. Restaking под ключ поэтому начинается с карты потоков наград и сценариев выхода оператора, а не с кода. Дальше — как это закрывается на каждом слое.

Что даёт повторный стейкинг: измеримые эффекты и сроки

Повторный стейкинг измеряется не числом подключённых сервисов, а тремя величинами: долей операций, которые проходят без ручного вмешательства, медианным временем вывода средств и количеством обращений в поддержку по расчётам наград. Эти же показатели снимаем до старта — иначе эффект нечем подтвердить.

Протокол на EigenLayer переиспользует уже размещённый стейк: один и тот же актив обеспечивает работу базовой сети и дополнительных сервисов. Капитал не нужно выводить и размещать заново — растёт отдача на ту же позицию, а не объём заблокированных средств.

Автоматизация выплат закрывает основную часть рутины: начисления, комиссии протокола и распределение наград идут по расписанию в смарт-контрактах, а доля автоматических операций доходит до 9 из 10. Вручную остаются спорные эпизоды и разбор штрафных сценариев — то, что действительно требует решения инженера.

Скорость вывода средств определяется очередью заявок: собираем их в пакеты и обрабатываем одним проходом, поэтому медианное время сокращается с суток до десятков минут. Вместе с ручным расчётом уходит целый класс отказов — двойные начисления, потерянные доли, неверный курс при конвертации.

Нагрузка на поддержку падает как следствие: статус позиции, история начислений и место в очереди видны пользователю, и вопрос «где моя награда» перестаёт быть типовым. Первые эффекты по автоматизации заметны в первую неделю после запуска, устойчивая статистика набирается за месяц.

Варианты реализации: готовые модули, форк, собственный код

Три пути к протоколу restaking различаются не только сроком до запуска, но и тем, кто отвечает за поведение контрактов дальше. Готовые модули дают работающие примитивы, форк — почти готовую систему с чужой архитектурой, собственная кодовая база — полный контроль над учётом долей, наград и слэшинга. С базовым слоем EigenLayer совместимы все три варианта — вопрос лишь в объёме нестандартной логики.

Практический критерий: пока модель наград и слэшинга укладывается в готовые шаблоны, сборка из модулей выигрывает — меньше собственного кода, который нужно проверять и сопровождать. Как только появляются свои правила распределения, ограничения готовых решений начинают диктовать экономику продукта, и собственная кодовая база становится способом не подстраивать её под чужой код. Переход между вариантами — это миграция состояния, поэтому точку развилки фиксируют до первого депозита.

Порядок работ: аудит, схема, сборка, проверка, передача

Порядок работ выстраиваем так, чтобы каждый шаг опирался на проверенный предыдущий: сначала инварианты фиксируются на бумаге, затем переходят в код, и только потом система допускается к сети, где ошибка стоит реальных активов.

1. Аудит схемы и текущего контура. Разбираем, какие активы и операторы участвуют, кто и за счёт чего получает награды, где проходят границы доверия. На выходе — карта ролей, инварианты и перечень сценариев, при которых протокол теряет управляемость.

2. Проектирование экономики и прав доступа. Определяем логику наград и слэшинга, лимиты на оператора, задержки вывода, роли администратора. Схему согласуем до первой строки кода: правки здесь стоят часы, после запуска — миграции.

3. Сборка ядра на EigenLayer. Реализуем контракты стратегий, обработку делегирования и распределение наград, покрываем ветки исполнения тестами. Отдельно проходим крайние случаи: нулевой депозит, одновременный вывод, смена оператора.

4. Внутренняя проверка. Статический анализ, фаззинг, сценарии повторного входа, замер расхода газа на массовых операциях — всё до выхода в сеть.

5. Тестовая сеть. Разворачиваем полный контур, воспроизводим реальные потоки депозитов и выводов, проверяем поведение при падении узла и росте нагрузки. Только после этого — основная сеть.

6. Передача протокола. Отдаём репозиторий, схемы, инструкции по развёртыванию и обновлению, обучаем вашу команду. Сопровождение первых недель в сети — по отдельному соглашению.

Что передаём на руки: код, схемы, регламенты, доступы

Передаём не архив с кодом, а комплект, по которому протокол restaking на EigenLayer можно вести без автора: ваша команда или наша поддержка поднимает стенд с нуля и разбирает инцидент по документам, а не по переписке. Комплект проходит приёмку вместе с вами — сверяем по репозиторию и прогоняем сценарии дежурной смены.

• Исходники и инфраструктура как код: репозитории контрактов, скриптов развёртывания и конфигураций узлов — сборка воспроизводится на чистом окружении.
• Схемы взаимодействия: поток задач между контрактами, оракулами и сервисами операторов, границы доверия и поведение системы при отказе узла.
• Матрица ролей и прав доступа: кто меняет параметры, приостанавливает приём ставок и выводит средства; разделение обязанностей между ключами.
• Документация протокола: механика restaking, экономические параметры, ограничения и точки расширения — новый инженер входит в проект без устных пояснений.
• Регламенты обслуживания: плановые работы, обновление контрактов, ротация ключей, резервное копирование и проверка восстановления.
• Инструкции для дежурной смены: пошаговые сценарии на типовые отказы — что смотреть первым, как откатить релиз, кого поднимать.
• Приёмочные сценарии и журналы: тесты на критичных путях, дашборды с пороговыми оповещениями и аудит действий — отклонение видно до инцидента.

Кейс: как протокол восстановил выплаты после сбоя оракула

Протокол рестейкинга на EigenLayer распределял награды между операторами через внешний источник цен: он подтверждал состояние стейкинга, и от его ответа зависел расчёт доли каждого участника. Один раз источник начал отдавать расходящиеся данные — часть операций зависла в статусе «подтверждение не получено», а награды перестали доходить до делегаторов.

До изменений доля зависших операций доходила до 18%: каждую разбирали вручную по логам и выпискам, один инцидент занимал у дежурного инженера от шести до девяти часов. За неделю поддержка принимала несколько десятков обращений, и половина из них — повторные, от тех же делегаторов.

Мы перестроили слой подтверждения: расчёт стал опираться на несколько независимых источников и сверять их между собой, а сомнительные ответы складываются в буфер неподтверждённых операций вместо остановки выплат. Пересчёт по буферу идёт автоматически, ручное вмешательство нужно только для подтверждения спорной операции, и каждое действие пишется в неизменяемый журнал — видно, кто и на каком основании принял решение.

После переработки доля зависших операций держится в пределах 0,4%, разбор сократился с часов до минут, а поток обращений в поддержку упал почти втрое — повторные исчезли как класс. Выплаты идут даже при расхождении источников: протокол доначисляет задним числом, когда подтверждение приходит.

Чем отличается restaking от обычного стейкинга?

Регулярный стейкинг решает одну задачу — подтверждение консенсуса сети. Вы вносите актив, получаете долю от эмиссии и комиссий за включение транзакций, а главный риск ограничен поведением валидатора и штрафом за нарушение правил протокола. Доходность здесь предсказуема: её определяют параметры сети и доступность валидатора, а не сторонние проекты.

Restaking меняет механику: тот же актив переиспользуется как залог в дополнительных сервисах, которым нужна экономическая защита, — оракулах, мостах, сетях хранения данных. Один депозит работает на несколько задач сразу, и доход раскладывается на несколько независимых потоков. Технически это контракты, которые учитывают вашу долю, передают её операторам и распределяют между ними обязанности.

Разница в рисках принципиальная. При обычном стейкинге вы отвечаете только за собственную валидацию, при restaking добавляются условия сторонних сервисов: их штрафы, ошибки в их коде, задержки вывода. Риск на ту же сумму залога становится кратко выше, и оценивать его по одной доходности нельзя — считать нужно по каждому потоку отдельно.

Требования к инфраструктуре тоже расходятся. Нужны операторы, способные одновременно держать несколько сервисов, разделять ключи и роли, вовремя отзывать делегированные доли. Отсюда и обязательная наблюдаемость: видеть, где и сколько залога задействовано и за какое время можно из него выйти.

Практический вывод: стейкинг — база, restaking — надстройка с несколькими источниками дохода и несколькими источниками штрафов. Мы проектируем такие протоколы на EigenLayer и начинаем с модели угроз, границ штрафования и сценариев выхода — до первой строки кода.

Технические сомнения: вывод средств, штрафы, аудит

Три вопроса инженеры задают раньше остальных: как выйти из протокола, кто отвечает за нарушение правил узла и что показывает проверка кода перед запуском. Ниже — как эти сценарии закрыты в архитектуре, которую мы собираем.

Кто платит штрафы валидатора?

Штраф удерживается из залоговой доли оператора, внесённой в обеспечение, а не из баланса пользователя. Под каждый набор задач выделяется отдельный лимит, поэтому сбой на одном сервисе не задевает остальные. Размер страховочного буфера и число одновременно активных задач — параметры конфигурации; мы считаем их на этапе моделирования рисков.

Как проходит аудит контрактов и обновление логики?

Перед запуском: статический анализ, прогон случайных и граничных сценариев на инварианты долей, проверка выхода и штрафа, внешний аудит с отчётом и разбором замечаний. Обновление идёт через контракт с задержкой исполнения и подтверждением несколькими ключами — одна роль не может незаметно поменять расчёт выплат. Полномочия разделены: у паузы и у обновления разные держатели.

Обсудим задачу: как мы оцениваем объём работ

Разработка протокола рестейкинга начинается не с кода, а с разбора экономики: правила начисления наград, логика штрафов и распределение дохода между оператором и делегатором определяют архитектуру сильнее любых интерфейсных пожеланий. Именно поэтому оценка объёма работ без входных данных превращается в условную вилку, которая рассыпается на первом же разборе сценариев.

Присылать нужно то, что уже есть: черновик модели, таблицы расчётов, схемы ролей, переписку с юристами, ограничения по срокам. Мы вернёмся с планом работ, разбитым по этапам, и отдельно отметим участки, где видим технический риск.

• Экономическая модель: как формируются награды, за что начисляется штраф, как делится доход между оператором и делегатором.
• Целевые сети и активы: где запускается рестейкинг, что принимается в качестве обеспечения и есть ли лимиты по ликвидности.
• Роли и права: кто меняет параметры протокола, кто может остановить его аварийно и как разделён доступ.
• Набор операторов: как проходит регистрация, проверка и вывод из набора, какие показатели влияют на статус.
• Интерфейс и интеграции: нужен ли личный кабинет, подключение кошельков, кастодиальных сервисов и внешнего учёта.
• Нагрузка и рост: ожидаемое число пользователей и операций, поведение протокола при пиковых очередях на вывод.
• Безопасность: нужен ли внешний аудит, какие отказы считаются критичными и какой срок восстановления допустим.
• Ограничения: сроки, состав вашей команды, требования регуляторов и юрисдикция запуска.

Опишите задачу в свободной форме — вернёмся с оценкой объёма работ и планом по этапам, без предварительных условий с вашей стороны.