Розробка restaking протоколу: де розривається механіка
Типовий протокол повторного стейкінгу впевнено проходить перші дні та починає розходитися з мережею через два-три тижні. Справа не в навантаженні, а в обліку частки: вона зафіксована на момент депозиту, тоді як оператор змінює набір сервісів і частково виводить кошти. У рішеннях поверх EigenLayer механіка та сама — змінюється лише джерело підтверджень.
Збої виплат накопичуються каскадом. Нагорода рахується за старим знімком частки, частина підтверджень надходить із затримкою, округлення під час перерахунку зміщують баланс на частки відсотка. Спочатку розходження маскують ручними донарахуваннями — тому воно спливає вже в основній мережі.
Архітектура протоколу має розділяти три незалежні шари: облік частки, розподіл нагороди між операторами та сервісами, життєвий цикл оператора з вікнами входу й виходу.
Коли все це живе в одному контракті, зміна набору сервісів тягне за собою перерахунок виплат, а відкат вимагає зупинки протоколу.
Окреме джерело відмов — неідемпотентна обробка подій: повтор породжує подвійне нарахування, пропуск — недоплату, яка не видна без звірки зі станом мережі. Ми ведемо журнал подій і звірку перед фіксацією, щоб розходження виявлялося до виплати, а не після звернення користувача.
Розробка restaking протоколу, яка це витримує, відрізняється не мовою контрактів, а моделлю обліку та межами відмови. Restaking під ключ тому починається з карти потоків нагород і сценаріїв виходу оператора, а не з коду. Далі — як це закривається на кожному шарі.
Що дає повторний стейкінг: вимірювані ефекти та строки
Повторний стейкінг вимірюється не кількістю підключених сервісів, а трьома величинами: часткою операцій, які проходять без ручного втручання, медіанним часом виведення коштів і кількістю звернень до підтримки щодо розрахунків нагород. Ці самі показники фіксуємо до старту — інакше ефект нічим підтвердити.
Протокол на EigenLayer повторно використовує вже розміщений стейк: той самий актив забезпечує роботу базової мережі та додаткових сервісів. Капітал не потрібно виводити й розміщувати заново — зростає віддача на ту саму позицію, а не обсяг заблокованих коштів.
Автоматизація виплат закриває основну частину рутини: нарахування, комісії протоколу та розподіл нагород ідуть за розкладом у смарт-контрактах, а частка автоматичних операцій сягає 9 із 10.
Вручну залишаються спірні епізоди та розбір штрафних сценаріїв — те, що справді потребує рішення інженера.
Швидкість виведення коштів визначається чергою заявок: збираємо їх у пакети й обробляємо одним проходом, тому медіанний час скорочується з доби до десятків хвилин.
Разом із ручним розрахунком зникає цілий клас відмов — подвійні нарахування, втрачені частки, неправильний курс під час конвертації.
Навантаження на підтримку падає як наслідок: статус позиції, історія нарахувань і місце в черзі видимі користувачу, і питання «де моя нагорода» перестає бути типовим. Перші ефекти з автоматизації помітні в перший тиждень після запуску, стійка статистика набирається за місяць.
Варіанти реалізації: готові модулі, форк, власний код
Три шляхи до протоколу restaking різняться не лише строком до запуску, а й тим, хто відповідає за поведінку контрактів далі.
Готові модулі дають працюючі примітиви, форк — майже готову систему з чужою архітектурою, власна кодова база — повний контроль над обліком часток, нагород і слешінгу. З базовим шаром EigenLayer сумісні всі три варіанти — питання лише в обсязі нестандартної логіки.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Збірка з готових модулів | Типова економіка, запуск у стислі строки, пілот на обмежений пул активів | Модель нагород і умови слешінгу задані авторами модулів; нестандартні сценарії потребують обв'язки |
| Форк відкритого протоколу | Потрібен швидкий старт із кастомними параметрами та власним інтерфейсом | Успадковуються архітектурні рішення та відомі обмеження; оновлення базової гілки переносяться вручну |
| Власні контракти | Відмінна від типової економіка, власні стратегії, вимоги до розкриття логіки | Найдовший цикл до запуску й постійний супровід з аудитом |
Практичний критерій: поки модель нагород і слешінгу вкладається в готові шаблони, збірка з модулів виграє — менше власного коду, який потрібно перевіряти й супроводжувати.
Щойно з'являються власні правила розподілу, обмеження готових рішень починають диктувати економіку продукту, і власна кодова база стає способом не підлаштовувати її під чужий код. Перехід між варіантами — це міграція стану, тому точку розвилки фіксують до першого депозиту.
Порядок робіт: аудит, схема, збірка, перевірка, передача
Порядок робіт вибудовуємо так, щоб кожен крок спирався на перевірений попередній: спочатку інваріанти фіксуються на папері, потім переходять у код, і лише після цього система допускається до мережі, де помилка коштує реальних активів.
-
Аудит схеми та поточного контуру. Розбираємо, які активи й оператори беруть участь, хто і за рахунок чого отримує нагороди, де проходять межі довіри. На виході — карта ролей, інваріанти й перелік сценаріїв, за яких протокол втрачає керованість.
-
Проєктування економіки та прав доступу. Визначаємо логіку нагород і слешінгу, ліміти на оператора, затримки виведення, ролі адміністратора. Схему узгоджуємо до першого рядка коду: правки тут коштують години, після запуску — міграції.
-
Збірка ядра на EigenLayer. Реалізуємо контракти стратегій, обробку делегування та розподіл нагород, покриваємо гілки виконання тестами. Окремо проходимо крайні випадки: нульовий депозит, одночасне виведення, зміна оператора.
-
Внутрішня перевірка. Статичний аналіз, фаззинг, сценарії повторного входу, замір витрат газу на масових операціях — усе до виходу в мережу.
-
Тестова мережа. Розгортаємо повний контур, відтворюємо реальні потоки депозитів і виведень, перевіряємо поведінку під час падіння вузла й зростання навантаження. Тільки після цього — основна мережа.
-
Передача протоколу. Віддаємо репозиторій, схеми, інструкції з розгортання й оновлення, навчаємо вашу команду. Супровід перших тижнів у мережі — за окремою угодою.
Що передаємо на руки: код, схеми, регламенти, доступи
Передаємо не архів із кодом, а комплект, за яким протокол restaking на EigenLayer можна вести без автора: ваша команда або наша підтримка піднімає стенд з нуля й розбирає інцидент за документами, а не за листуванням.
Комплект проходить приймання разом із вами — звіряємо за репозиторієм і проганяємо сценарії чергової зміни.
- Джерельні коди та інфраструктура як код: репозиторії контрактів, скриптів розгортання й конфігурацій вузлів — збірка відтворюється в чистому середовищі.
- Схеми взаємодії: потік завдань між контрактами, оракулами та сервісами операторів, межі довіри й поведінка системи під час відмови вузла.
- Матриця ролей і прав доступу: хто змінює параметри, призупиняє приймання ставок і виводить кошти; розподіл обов'язків між ключами.
- Документація протоколу: механіка restaking, економічні параметри, обмеження та точки розширення — новий інженер входить у проєкт без усних пояснень.
- Регламенти обслуговування: планові роботи, оновлення контрактів, ротація ключів, резервне копіювання та перевірка відновлення.
- Інструкції для чергової зміни: покрокові сценарії на типові відмови — що дивитися першим, як відкотити реліз, кого піднімати.
- Приймальні сценарії та журнали: тести на критичних шляхах, дашборди з пороговими оповіщеннями й аудит дій — відхилення видно до інциденту.
Кейс: як протокол відновив виплати після збою оракула
Протокол рестейкінгу на EigenLayer розподіляв нагороди між операторами через зовнішнє джерело цін: він підтверджував стан стейкінгу, і від його відповіді залежав розрахунок частки кожного учасника.
Одного разу джерело почало віддавати розбіжні дані — частина операцій зависла у статусі «підтвердження не отримано», а нагороди перестали доходити до делегаторів.
До змін частка завислих операцій сягала 18%: кожну розбирали вручну за логами й виписками, один інцидент займав у чергового інженера від шести до дев'яти годин. За тиждень підтримка приймала кілька десятків звернень, і половина з них — повторні, від тих самих делегаторів.
Ми перебудували шар підтвердження: розрахунок почав спиратися на кілька незалежних джерел і звіряти їх між собою, а сумнівні відповіді складаються в буфер непідтверджених операцій замість зупинки виплат.
Перерахунок за буфером іде автоматично, ручне втручання потрібне лише для підтвердження спірної операції, і кожна дія пишеться в незмінюваний журнал — видно, хто і на якій підставі ухвалив рішення.
Після переробки частка завислих операцій тримається в межах 0,4%, розбір скоротився з годин до хвилин, а потік звернень до підтримки впав майже втричі — повторні зникли як клас.
Виплати йдуть навіть за розходження джерел: протокол донараховує заднім числом, коли підтвердження надходить.
Чим відрізняється restaking від звичайного стейкінгу?
Регулярний стейкінг вирішує одне завдання — підтвердження консенсусу мережі. Ви вносите актив, отримуєте частку від емісії та комісій за включення транзакцій, а головний ризик обмежений поведінкою валідатора й штрафом за порушення правил протоколу.
Дохідність тут передбачувана: її визначають параметри мережі та доступність валідатора, а не сторонні проєкти.
Restaking змінює механіку: той самий актив повторно використовується як застава в додаткових сервісах, яким потрібен економічний захист, — оракулах, мостах, мережах зберігання даних. Один депозит працює на кілька завдань одразу, і дохід розкладається на кілька незалежних потоків.
Технічно це контракти, які враховують вашу частку, передають її операторам і розподіляють між ними обов'язки.
Різниця в ризиках принципова. За звичайного стейкінгу ви відповідаєте лише за власну валідацію, за restaking додаються умови сторонніх сервісів: їхні штрафи, помилки в їхньому коді, затримки виведення.
Ризик на ту саму суму застави стає в рази вищим, і оцінювати його за однією дохідністю не можна — рахувати потрібно за кожним потоком окремо.
Вимоги до інфраструктури теж різняться. Потрібні оператори, здатні одночасно тримати кілька сервісів, розділяти ключі й ролі, вчасно відкликати делеговані частки. Звідси й обов'язкова спостережуваність: бачити, де і скільки застави задіяно і за який час можна з неї вийти.
Практичний висновок: стейкінг — база, restaking — надбудова з кількома джерелами доходу й кількома джерелами штрафів. Ми проєктуємо такі протоколи на EigenLayer і починаємо з моделі загроз, меж штрафування та сценаріїв виходу — до першого рядка коду.
Технічні сумніви: виведення коштів, штрафи, аудит
Три питання інженери ставлять раніше за інших: як вийти з протоколу, хто відповідає за порушення правил вузла і що показує перевірка коду перед запуском. Нижче — як ці сценарії закриті в архітектурі, яку ми збираємо.
Як вивести активи, якщо ми вирішимо піти з протоколу?
Виведення йде через чергу: запит фіксує частку, нагороди за нею припиняються, і через період розблокування активи повертаються на адресу власника.
Довжину періоду задають під час розгортання, змінити її заднім числом не можна — інакше останній учасник виходив би в момент розрахунку. Увесь час черги частка залишається у власника, а не в оператора.
Хто платить штрафи валідатора?
Штраф утримується із заставної частки оператора, внесеної в забезпечення, а не з балансу користувача. Під кожен набір завдань виділяється окремий ліміт, тому збій на одному сервісі не зачіпає решту.
Розмір страхувального буфера й кількість одночасно активних завдань — параметри конфігурації; ми рахуємо їх на етапі моделювання ризиків.
Як проходить аудит контрактів і оновлення логіки?
Перед запуском: статичний аналіз, прогін випадкових і граничних сценаріїв на інваріанти часток, перевірка виходу й штрафу, зовнішній аудит зі звітом і розбором зауважень.
Оновлення йде через контракт із затримкою виконання та підтвердженням кількома ключами — одна роль не може непомітно змінити розрахунок виплат. Повноваження розділені: у паузи й в оновлення різні власники.
Обговоримо задачу: як ми оцінюємо обсяг робіт
Розробка протоколу рестейкінгу починається не з коду, а з розбору економіки: правила нарахування нагород, логіка штрафів і розподіл доходу між оператором і делегатором визначають архітектуру сильніше за будь-які інтерфейсні побажання.
Саме тому оцінка обсягу робіт без вхідних даних перетворюється на умовну вилку, яка розсипається вже на першому розборі сценаріїв.
Надсилати потрібно те, що вже є: чернетку моделі, таблиці розрахунків, схеми ролей, листування з юристами, обмеження за строками. Ми повернемося з планом робіт, розбитим за етапами, і окремо зазначимо ділянки, де бачимо технічний ризик.
- Економічна модель: як формуються нагороди, за що нараховується штраф, як ділиться дохід між оператором і делегатором.
- Цільові мережі та активи: де запускається рестейкінг, що приймається як забезпечення і чи є ліміти за ліквідністю.
- Ролі та права: хто змінює параметри протоколу, хто може зупинити його аварійно і як розділено доступ.
- Набір операторів: як проходять реєстрація, перевірка та виведення з набору, які показники впливають на статус.
- Інтерфейс та інтеграції: чи потрібен особистий кабінет, підключення гаманців, кастодіальних сервісів і зовнішнього обліку.
- Навантаження та зростання: очікувана кількість користувачів і операцій, поведінка протоколу за пікових черг на виведення.
- Безпека: чи потрібен зовнішній аудит, які відмови вважаються критичними і який строк відновлення припустимий.
- Обмеження: строки, склад вашої команди, вимоги регуляторів і юрисдикція запуску.
Опишіть задачу у вільній формі — повернемося з оцінкою обсягу робіт і планом за етапами, без попередніх умов із вашого боку.
