Розробка оператора EigenLayer
Оператор EigenLayer — учасник, який управляє інфраструктурою для Actively Validated Services. Оператори отримують переставлені ETH від stakers у делегування, реєструються в AVS та виконують їх роботу валідації. Це бізнес-модель: оператор надає інфраструктуру та професійне управління, отримуючи частку винагород.
Роль оператора в екосистемі
Stakers довіряють операторам свій переставлений ETH. При порушенні оператором — слешинг бьє по stakers, які йому делегували. Це означає, що репутація оператора критична.
AVS вибирають операторів на основі: розміру делегованого stake (безпека), історичної надійності (uptime), репутації.
Оператор несе відповідальність: за правильне виконання роботи валідації для кожного AVS, у якому він бере участь.
Технічна інфраструктура оператора
Реєстрація EigenLayer
IDelegationManager.OperatorDetails memory operatorDetails = IDelegationManager.OperatorDetails({
earningsReceiver: operatorAddress,
delegationApprover: address(0), // Permissionless delegation
stakerOptOutWindowBlocks: 50400 // ~7 днів
});
delegationManager.registerAsOperator(operatorDetails, metadataURI);
metadataURI вказує на JSON з публічною інформацією оператора: назва, веб-сайт, комісія. Перший крок онбордингу.
AVS Operator Node
Для кожного AVS, у якому оператор бере участь — потрібно запустити окремий node software. Вимоги різні для різних AVS:
EigenDA operator:
- Вимагає зберігання DA chunks
- Участь у розподіленому сховищі та пошуку
- Мінімальний stake: варіюється за кворумом
Generic AVS operator:
- Моніторинг on-chain завдань
- Off-chain обчислення
- BLS підпис результатів
- Передача до aggregator
Ключові: BLS ключі
Оператори використовують BLS (Boneh-Lynn-Shacham) криптографію для підписання. BLS дозволяє агрегувати тисячі підписів в один — ключовий для масштабованості AVS.
Генерація BLS ключа (з використанням EigenLayer CLI):
eigenlayer operator keys create --key-type bls my-bls-key
# Збережіть зашифрований keystore + пароль у безпечному сховищі
ECDSA ключ: для on-chain операцій (реєстрація, отримання винагород).
HSM рекомендується: у production — BLS та ECDSA ключі в HSM (Hardware Security Module). AWS CloudHSM, YubiHSM, або Hashicorp Vault з HSM backend.
Моніторинг та доступність
AVS стежать за доступністю операторів. Offline оператор = пропущені завдання = потенційний слешинг (залежить від AVS).
Потрібний моніторинг:
- Здоров'я вузла: процес живий, підключений до RPC
- Обробка завдань: успішне виконання завдань, без пропусків
- Підключення до aggregator: зв'язок зі сервісом aggregator
- BLS підписання: успішне підписання
Географічна надлишковість: для високої доступності — первинний та резервний вузли в різних датацентрах/регіонах. Failover при недоступності первинного.
Економіка оператора
Комісія оператора: оператор утримує % від винагород, отриманих його stakers. Типовий діапазон 5-15%. Конкурентний ринок.
Потоки винагород AVS: кожний AVS платить операторам по-різному. Потрібно розраховувати очікуваний APY з урахуванням:
- Розміру делегованого stake (більший stake = пропорційно більше винагород)
- Кількості AVS, у яких бере участь
- Ризику слешингу кожного AVS
Розрахунок ризику слешингу: якщо один AVS слешит оператора на 1% — бьє по всім stakers, які йому делегували. Репутаційна та фінансова шкода.
Бізнес-розвиток оператора
Оператори конкурують за делегований stake. Диференціатори:
- Прозора історія: публічна історія uptime, завдань, слешингів (все on-chain)
- Безпека: публічний security audit інфраструктури вузла
- Конкурентна комісія: баланс між привабливістю для stakers та власною маржею
- Покриття AVS: широкий набір AVS = диверсифікований потік винагород для stakers
- Присутність спільноти: Discord, Twitter, регулярні оновлення
Великі оператори (P2P.org, Figment, Chorus One) конкурують з десятками інших. Бар'єр входу — надійна інфраструктура та достатній bootstrap stake.
Розробка node software оператора для конкретного AVS — 2-6 тижнів. Запуск production оператора з моніторингом та безпекою — 2-3 місяці.