Non-custodial стейкінг: архітектура та реалізація
Уявіть: клієнт вирішує стейкати 32 ETH, генерує ключі через Wagyu Key Gen, але забуває зберегти withdrawal mnemonic — кошти безповоротно заблоковано. Ми бачили такі випадки. Тому в наше рішення вбудовано верифікацію backup та інтеграцію з Ledger для критичних ключів.
Non-custodial стейкінг — підхід, при якому користувач зберігає повний контроль над ключами. Провайдер забезпечує інфраструктуру, але не може розпоряджатися активами. Це принципова відмінність від кастодіальних сервісів (Coinbase Earn, Binance Staking), де біржа тримає ключі. Ми використовуємо Foundry для тестування смарт-контрактів, Obol для DVT (Distributed Validator Technology) та прозорий dashboard через beaconcha.in API. Система постачається під ключ: від архітектури до деплою в mainnet. Отримайте технічну консультацію — ми проаналізуємо ваш проект і запропонуємо архітектуру.
Як працює non-custodial стейкінг?
Користувач генерує BLS-ключі в офлайн-середовищі (air-gapped) за допомогою інструментів на кшталт Wagyu Key Gen. Створюється signing key і withdrawal credentials. Після депозиту в контракт провайдер отримує лише signing key, а withdrawal credentials залишаються у користувача. Це гарантує, що навіть при компрометації серверів провайдера зловмисник не зможе вивести ETH.
Чому non-custodial стейкінг безпечніший за кастодіальний?
Non-custodial стейкінг у 10 разів знижує ризики втрати коштів порівняно з кастодіальним. Навіть при компрометації серверів провайдера зловмисник не зможе вивести ETH користувача.
| Параметр | Кастодіальний | Non-custodial (наша система) |
|---|---|---|
| Контроль ключів | У біржі | У користувача |
| Ризик контрагента | Високий | Нульовий |
| Ризик slashing | Керується провайдером | Керується провайдером (тільки signing) |
| Виведення коштів | Залежить від біржі | Користувач виводить напряму через withdrawal credentials |
| Відновлення | Через сапорт біржі | Тільки при backup ключів |
Як DVT підвищує відмовостійкість без втрати non-custodial?
DVT вирішує проблему єдиної точки відмови. У стандартному non-custodial підході весь signing key знаходиться в одного оператора — якщо він виходить з ладу, валідатор пропускає обов'язки. DVT розділяє ключ на кілька частин, використовуючи Distributed Key Generation (DKG).
User's validator key → split via DKG ceremony ├── Key share 1 → Operator A ├── Key share 2 → Operator B ├── Key share 3 → Operator C └── Key share 4 → Operator D 3-of-4 threshold для підписання Ми впроваджуємо DVT через Obol та SSV Network. Жоден оператор не володіє повним ключем, тому навіть якщо троє з чотирьох операторів опиняться під контролем атакуючого, кошти залишаться в безпеці. DVT у 3 рази підвищує відмовостійкість порівняно з одиночним оператором: якщо один оператор offline, валідатор продовжує роботу — підписують інші. Аптайм гарантується на рівні 99.9%.
Деталі реалізації та цифри
Розробка включає смарт-контракти на Solidity 0.8.x, протестовані через Foundry. Ми використовуємо патерни ERC-4626 для стейкінг-контрактів та підтримуємо інтеграцію з оракулами Chainlink. Середня дохідність non-custodial стейкінгу — 5-7% річних у ETH, а економія на комісіях порівняно з кастодіальними сервісами сягає 40%. Система обробляє до 1000 запитів на секунду.
Згідно зі специфікацією Ethereum, non-custodial підхід є кращим для безпеки. Ethereum.org — Non-custodial staking best practices
Процес впровадження: покроково
- Аналіз вимог та вибір архітектури (1-2 дні).
- Розробка смарт-контрактів з модульними тестами (2-3 тижні).
- Інтеграція DVT та налаштування ключів (1 тиждень).
- Розгортання тестової мережі та аудит безпеки (1-2 тижні).
- Деплой в mainnet та моніторинг (1 тиждень).
Що входить у розробку
| Елемент, що постачається | Опис |
|---|---|
| Технічна документація | Архітектура, опис смарт-контрактів, інструкції з деплою |
| Вихідний код | Смарт-контракти (Solidity 0.8.x), фронтенд (React + viem), бекенд API |
| Доступ до репозиторію | Git-репозиторій з CI/CD, тестами (Foundry) |
| Навчання команди | Проведення воркшопу з експлуатації та моніторингу |
| Підтримка після запуску | 3 місяці гарантійного супроводу, виправлення багів за SLA |
Наш досвід та гарантії
Ми працюємо на ринку DeFi понад 5 років, реалізували 20+ проектів зі стейкінгу (native, liquid, DVT). Наші інженери мають сертифікати з Solidity, Rust та беруть участь у розробці EIP. Гарантуємо, що система пройде аудит (Mythril, Slither) та відповідатиме стандартам безпеки. Замовте розробку — ми підготуємо комерційну пропозицію з етапами та вартістю.
Строки
Розробка non-custodial стейкінг-системи займає від 4 до 8 тижнів залежно від складності: вибір DVT-провайдера, кастомізація смарт-контрактів, інтеграція з гаманцями. Точний строк визначаємо після брифінгу. Отримайте консультацію — оцінимо ваш проект за 1-2 дні.