EigenLayer — это набор смарт-контрактов на Ethereum и offchain-инфраструктуры, который позволяет стейкерам повторно использовать (restake) уже застейканный ETH, LST и другие токены для обеспечения безопасности внешних сервисов (AVS).
На этой странице — именно архитектура: какие есть контракты, как они связаны между собой, где находятся restakers, операторы и AVS, как строятся такие сервисы, как EigenDA.
Уровни архитектуры EigenLayer
Условно стек можно разделить на четыре уровня:
- Уровень Ethereum.
Консенсус и исполнение Ethereum, валидаторы Beacon Chain, обычные транзакции L1.
- Смарт-контракты EigenLayer на Ethereum.
Набор core-контрактов для:
- учёта депонированных активов (стратегий),
- делегации стейка операторам,
- регистрации AVS и наборов операторов,
- распределения наград и применения слэшинга.
- Операторы (Operator layer).
Узлы, на которые делегируют стейк. Они запускают дополнительное ПО AVS и подписывают данные/результаты.
- AVS (Actively Validated Services).
Внешние сервисы поверх EigenLayer (например, EigenDA): у каждого есть:
- onchain-контракты — регистрируют операторов, описывают правила слэшинга и расчёта наград,
- offchain-контейнер/нода — исполняет логику сервиса (DA, оракулы, мосты и т.п.).
Core-контракты EigenLayer на Ethereum
В документации выделяют несколько ключевых core-контрактов.
| Контракт | Роль в архитектуре |
|---|---|
| StrategyManager | Ведёт учёт депозитов restakers в стратегиях (ERC-20/LST/прочие токены), считает доли и готовит данные для слэшинга и распределения наград. |
| DelegationManager | Отвечает за делегацию стейка операторам и за процесс вывода (undelegate/withdraw). Хранит, сколько активов из каждой стратегии делегировано каждому оператору, и учитывает слэшинг. |
| EigenPodManager | Специализированный менеджер для native restaking: связывает валидаторов Beacon Chain с EigenLayer через EigenPods, обрабатывает обновления баланса и выход валидаторов. |
| AllocationManager | Управляет Operator Sets: формирует наборы операторов для AVS, регистрирует операторов в этих наборах, отслеживает объём стейка и даёт AVS право инициировать слэшинг по конкретному набору. |
| RewardsCoordinator | Координирует распределение наград от AVS между операторами и restakers, отслеживает начисления и обеспечивает их получение. |
| PermissionController, KeyRegistrar | Контролируют права вызовов в core-контрактах и регистрируют криптографические ключи операторов (ECDSA/BN254) с требованием уникальности ключей. |
В старых версиях использовался отдельный AVSDirectory, сейчас его функции постепенно переносит AllocationManager.
Multichain-компоненты и расширение за пределы Ethereum
Хотя «источник» стейка — Ethereum, архитектура EigenLayer изначально проектируется под multichain-сценарии:
- CertificateVerifier — проверяет «сертификаты» (результаты offchain-задач) на других сетях и связывает их с состоянием EigenLayer.
- OperatorTableUpdater — обновляет таблицу операторов и их стейка в Operator Set на целевых сетях, используя корневой хеш стейка и доказательства хранения.
- CrossChainRegistry — регистрирует Operator Sets в мультичейн-протоколе и помогает строить глобальный «корень стейка» для использования в других сетях.
Это позволяет AVS работать не только на Ethereum, но и, например, на L2/альт-L1, используя один и тот же набор операторов и одну экономическую базу стейка.
Поток рестейкинга: от депозита до AVS
Упрощённый сценарий для restaker’а:
- Депозит.
Пользователь вносит:
- либо native ETH через EigenPod (валидатор связывает withdrawal-credentials с EigenLayer),
- либо LST/другие токены в стратегию StrategyManager.
- Учёт в стратегии.
StrategyManager фиксирует объём депозита в соответствующей стратегии (для ETH-валидаторов это специальная стратегия beaconChainETH).
- Делегация оператору.
Через DelegationManager restaker делегирует свои «shares» выбранному оператору. Для каждой стратегии хранится, сколько долей делегировано какому оператору.
- Подключение к AVS.
Оператор регистрируется в нужных Operator Sets (через AllocationManager), определённых AVS. AVS-контракты видят, какой объём стейка стоит за каждым оператором в конкретном наборе.
- Работа AVS и награды.
Offchain-ноды AVS выполняют работу (DA, оракулы, мосты), передают доказательства onchain; AVS-контракты через RewardsCoordinator распределяют награды операторам и их делегаторам.
- Слэшинг.
При нарушении правил AVS отправляет в AllocationManager «запрос слэшинга» по конкретному оператору и стратегии; дальше StrategyManager и DelegationManager применяют штраф к долям стейкера и оператора.
Важно: EigenLayer пытается разделить учёт стейка, делегацию, слэшинг и награды по контрактах, чтобы AVS интегрировались через понятные интерфейсы, не дублируя общую логику.
AVS: onchain-контракты и offchain-контейнеры
С точки зрения архитектуры EigenLayer у любого AVS есть два компонента:
- Onchain-часть (контракты AVS).
Здесь описывается:
- какие Operator Sets используются;
- какие ключи/подписи нужны от операторов;
- какие события считаются нарушением и каков объём слэшинга;
- как рассчитываются и распределяются награды.
- Offchain-часть (контейнер/нода AVS).
Запускается операторами и:
- принимает задачи (блоки DA, кросс-чейн-сообщения, запросы оракула);
- выполняет проверку, хранение или вычисления;
- формирует подписи/сертификаты, которые потом проверяются onchain-контрактами.
Такая модель позволяет:
- писать AVS на разных языках (Rust, Go, C++ и т.д.);
- переносить одну и ту же AVS-логику на разные сети, опираясь на общую базу стейка и операторов.
Пример: архитектура EigenDA поверх EigenLayer
EigenDA — это AVS-сервис доступности данных (DA) поверх EigenLayer:
- использует restaked ETH/EIGEN и пул операторов EigenLayer;
- offchain-ноды EigenDA принимают блобы данных от L2/роллапов, кодируют их (erasure coding) и распределяют по операторам;
- onchain-контракты EigenDA фиксируют обязательства по хранению и проверяют сертификаты доступности данных;
- интеграции с L2 (например, Mantle Network) показывают, как EigenDA заменяет собственный DA и масштабирует пропускную способность по данным.
Для EigenLayer это «эталонный» AVS-кейс: он показывает, как через рестейкинг строится масштабируемый DA-слой без отдельного PoS.
Механика вывода и задержки (withdrawal delay)
Архитектурно важная часть — очереди вывода и задержки:
- Любой вывод (undelegate/withdraw) проходит через delay-очередь в core-контрактах EigenLayer.
- Для native restaking отдельный путь: средства валидатора сначала попадают в EigenPod, затем через DelayedWithdrawalRouter доступны для вывода после выдержки таймера.
Зачем это нужно:
- даёт время реагировать на найденные уязвимости или подозрительное поведение операторов/AVS;
- позволяет корректно обработать потенциальный слэшинг, чтобы стейкеры не «убегали» раньше фиксации нарушения.
С архитектурной точки зрения delay-механика — это «страховой буфер» между сегодняшним состоянием сети и возможными штрафами в ближайшем будущем.
Особенности дизайна и компромиссы
Плюсы архитектуры:
- Чёткое разделение ответственности:
- StrategyManager — депозит/учёт;
- DelegationManager — делегация и вывод;
- AllocationManager — наборы операторов для AVS;
- RewardsCoordinator — награды;
- EigenPodManager — мост к Beacon Chain.
- Переиспользуемость:
- AVS интегрируются через стандартные интерфейсы,
- операторы могут обслуживать несколько AVS одновременно.
- Масштабируемость:
- multichain-контракты и Operator Sets позволяют выносить проверку и безопасный стейк на другие сети.
Компромиссы:
- Сложность интеграции AVS: разработчикам нужно понимать и core-контракты, и очереди, и слэшинг.
- Риск ошибок в связках «DelegationManager ↔ EigenPodManager ↔ AVS-контракты» — отсюда большое внимание к аудитам и баг-баунти.
- Необходимость управлять каскадными рисками LST/LRT и shared security — это уже тема разделов Рестейкинг и LRT.