Розробка протоколу рестейкингу
Рестейкинг — переиспользование застейкованого ETH для забезпечення безпеки додаткових протоколів крім Ethereum. EigenLayer вигадав цю концепцію та зібрав $15B+ TVL. Ідея: економічна безпека Ethereum (32M+ ETH у стейкингу) може бути "знята в оренду" іншими програмами — oracle мережами, DA шарами, кросс-ланцюговими мостами — без необхідності будувати свій власний набір валідаторів.
Концептуальна архітектура EigenLayer
AVS (Actively Validated Service): сервіс, який використовує рестейкинг для своєї безпеки. Приклади: EigenDA (data availability), Espresso Systems (shared sequencer), Lagrange (ZK coprocessor).
Оператор: оператор, який управляє валідаторами та реєструється в одному або кількох AVS. Приймає на себе додаткові умови слешингу AVS.
Staker → Restaker: звичайний стейкер ETH або власник токена ліквідного стейкингу депонує в EigenLayer. Делегує свій stake операторам.
Умови слешингу: кожен AVS визначає умови слешингу для своїх операторів. Двійне підписання в протоколі AVS = втрата частини рестейкованого ETH. Це "ціна" за участь у безпеці AVS.
Staker ETH
↓ restakes через EigenLayer
Контракт рестейкингу (EigenPod)
↓ делегує до
Оператор
├── валідує Ethereum (обов'язково)
├── валідує AVS_1 (опціонально)
├── валідує AVS_2 (опціонально)
└── валідує AVS_N (опціонально)
Технічні компоненти протоколу рестейкингу
EigenPod
EigenPod — смарт-контракт, який "бачить", що користувач має ETH у стейкингу на Beacon Chain. Верифікація відбувається через EIP-4788 (Beacon Chain root доступний на-chain) + Merkle proofs.
// Спрощено: верифікація облікових даних валідатора
function verifyWithdrawalCredentials(
uint64[] calldata oracleTimestamps,
BeaconChainProofs.StateRootProof calldata stateRootProof,
uint40[] calldata validatorIndices,
bytes[] calldata validatorFieldsProofs,
bytes32[][] calldata validatorFields
) external {
// Перевірка через стан Beacon Chain root
// Нарахування shares рестейкингу
}
Менеджер делегування
Управляє делегуванням від стейкерів до операторів. Стейкер вибирає оператора, делегує свої shares. Оператор тепер відповідає за цей stake при взаємодії з AVS.
Затримка вивільнення: при скасуванні делегування — затримка вивільнення (зараз 7 днів у EigenLayer). Захист AVS від раптового відтоку stake.
Реєстрація AVS та Slasher
Кожен AVS розгортає свій контракт slasher, реєструє умови слешингу в EigenLayer Registry. Оператор при реєстрації в AVS дає згоду на ці умови.
При виявленні порушення — механізм слешингу AVS викликає slash() в EigenLayer, який зменшує shares порушника.
Токени ліквідного рестейкингу (LRT)
Якщо звичайний рестейкинг через EigenLayer є неліквідним (кошти заморожені), токени ліквідного рестейкингу (eETH EtherFi, ezETH Renzo, pufETH Puffer) забезпечують ліквідність поверх рестейкингу.
Користувач: депонує ETH → отримує LRT → використовує в DeFi. Протокол: депонує ETH в EigenLayer → делегує операторам → отримує винагороди AVS → розподіляє LRT мачах.
Автоматичне розподіл рестейкингу: протокол стратегічно розподіляє ETH між AVS для оптимального yield при прийнятному ризику. Реалізується через Strategy Manager.
Архітектура LRT
Користувач депонує ETH
↓ контракт EtherFi/Renzo/Puffer
↓ депонує в EigenLayer
↓ делегує операторам (кілька)
↓ оператори реєструються в AVS_1, AVS_2, ...
↓ винагороди AVS надходять
↓ yield розподіляється stakers
Користувач отримує LRT (eETH/ezETH/pufETH)
→ ліквідний, використовується в DeFi
→ курс обміну зростає від винагород
Ризики рестейкингу та їх управління
Ризик коррельованого слешингу: якщо оператор реєструється в 5 AVS та отримує слешинг в одному — втрачає частину stake, який забезпечував усіх 5. Ризик каскадного слешингу.
Ризик якості AVS: не всі AVS однаково безпечні. Низькоякісний AVS з багом у slasher може випадково заслешити валідаторів без реального порушення. Оператори та протоколи LRT мають обережно вибирати AVS.
Ризик концентрації: якщо більшість рестейку зосереджена у кількох операторів — атака на них підриває багато AVS одночасно.
Ризик левереджу: рестейкинг — це певною мірою левередж на ETH stake. "Один і той же" 32 ETH забезпечує безпеку Ethereum + N інших протоколів. Якщо загальна слешинг-відповідальність перевищить вартість stake — система втрачає узгодженість.
Програмування власного AVS
Якщо ви будуєте AVS поверх EigenLayer:
Middleware контракти: контракти на Ethereum для реєстрації операторів та управління умовами.
Off-chain node software: програма, яку запускають оператори. Виконує фактичну роботу валідації AVS.
Task Manager: контракт, який виставляє завдання операторам та агрегує їх відповіді. На основі кворуму: завдання вважається виконаним при підписанні N-of-M операторами.
Умови слешингу: чітко визначені та обмежені умови. Мають бути об'єктивно верифіковані — не можна карати за суб'єктивні причини.
Розробка власного протоколу рестейкингу або AVS — надзвичайно складне завдання, що вимагає глибокого розуміння консенсусу Ethereum, безпеки смарт-контрактів та внутрішніх компонентів EigenLayer. Тривалість — 6-12 місяців.