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