Розробка DeFi-протоколу
Команда запускає лендинг-протокол, натхненний Aave v3. На етапі тестування все працює. Після деплою на mainnet через 48 годин оракул Chainlink повертає застарілу ціну — liquidation threshold пробиває безпечні позиції. Ліквідатори дренують заставний пул на значну суму, поки команда розбирається в чому справа. Проблема не в самому Chainlink — у відсутності staleness check: контракт не перевіряв updatedAt з latestRoundData(). Наша команда стикалася з подібними інцидентами та виробила системний підхід до розробки DeFi-протоколів, включаючи смарт-контракти для lending protocol, AMM, cross-chain bridge, а також liquidity pool для yield farming.
Розробка DeFi-протоколу — це не просто Solidity-код. Це система інваріантів, які повинні триматися за будь-яких ринкових умов, MEV-атак та форс-мажорів на рівні інфраструктури. Ми використовуємо формальні специфікації та property-based тести для виявлення вразливостей на ранніх етапах. Гарантуємо прозорість на кожному етапі.
Чому DeFi-протоколи ламаються на етапі дизайну
Oracle manipulation через flash loan
Типова схема: атакуючий бере flash loan на значну суму в Aave, маніпулює ціною в Uniswap v2 пулу з низькою ліквідністю, використовує цей пул як ціновий оракул, займає під завищену заставу, не повертає позику. Протоколи, які використовують token.balanceOf(pool) або spot price з AMM як оракул — вразливі за визначенням.
Захист працює на кількох рівнях:
-
TWAP замість spot price. Uniswap v3 надає
OracleLibrary.consult()для розрахунку time-weighted average price. Вікно в 30 хвилин робить flash loan маніпуляцію економічно невигідною — потрібно утримувати позицію кілька блоків, кожен з ризиком арбітражу. -
Chainlink з fallback. Primary source — Chainlink, fallback — Uniswap v3 TWAP. Якщо Chainlink повертає ціну з
updatedAtстаршим за 3600 секунд або answer < 0 — перемикання на TWAP з emit події для моніторингу. -
Circuit breaker на відхилення. Якщо ціна за один блок змінилася більш ніж на 15% — транзакція реверсується. Параметр налаштовується через governance з timelock.
Reentrancy в cross-protocol взаємодіях
AMM-протокол викликає токен при swap. Якщо токен реалізує ERC-777 з tokensReceived хуком — атакуючий контракт отримує управління в середині swap, до оновлення внутрішніх балансів пулу. Це не теорія: атака на Uniswap v1 через ERC-777 була однією з перших публічних експлойтів на DEX. Докладніше про reentrancy можна прочитати на Wikipedia.
У сучасних протоколах проблема ускладнюється: callback-патерни (uniswapV3SwapCallback, flashLoanReceiver) навмисно передають управління зовнішньому коду. Захист будується через invariant check: перед callback фіксується стан, після — перевіряється що інваріанти дотримані.
Liquidation mechanics та bad debt
При різкому падінні ринку на 40%+ за один блок (Ethereum у кризовий період впав на 50% за кілька годин) ліквідація може не встигнути. Залог коштує менше боргу — протокол отримує bad debt. Compound v2 зіткнувся з цим, MakerDAO ввів механізм Emergency Shutdown саме як останній рубіж.
Параметри ліквідації вимагають математичного моделювання: loan-to-value ratio, liquidation threshold, liquidation bonus, close factor — всі ці параметри повинні бути відкалібровані під волатильність конкретного активу. WBTC та мем-токен не можуть мати однаковий LTV. Погана gas-оптимізація може спричинити значні щомісячні витрати, а оптимізація на етапі розробки знижує ці витрати на 30-50%. Неоптимізовані контракти — понад 2000 рядків коду, що збільшує час аудиту в 3 рази.
Як ми забезпечуємо безпеку оракулів у DeFi-протоколах?
Застосовуємо багаторівневу стратегію: первинний оракул Chainlink з TWAP-резервом, circuit breaker на аномальні рухи ціни, та обов’язкову валідацію свіжості даних. Додатково використовуємо keepers на Tenderly для автоматичного перемикання джерел при збоях.
| Ризик | Контрзаходи | Інструменти |
|---|---|---|
| Маніпуляція оракулом | TWAP, circuit breaker, fallback оракули | Chainlink, Uniswap v3 TWAP |
| Reentrancy | Reentrancy guard, invariant checks після callback | OpenZeppelin ReentrancyGuard |
| Неправильна ліквідація | Моделювання параметрів, stress test | Власні скрипти на Foundry |
Архітектура протоколу
Модульна структура контрактів
Монолітний контракт на 3000 рядків — перша помилка в DeFi-протоколі. Не через естетику, а тому що:
- Перевищує ліміт байткоду EVM (24 KB)
- Неможливо замінити окремий модуль без повного редеплою
- Аудит займає в 3x довше і коштує відповідно
Використовуємо Diamond Pattern (EIP-2535) для протоколів з багатою функціональністю: окремі facets для lending, liquidation, oracle, governance. Сховище — спільний Diamond Storage через keccak256-слоти (ERC-7201). Докладніше про Diamond Pattern можна прочитати на GitHub.
Для простіших випадків — розділення на Core (незмінна логіка), Periphery (допоміжні контракти, можна оновлювати) та Governance. Цей патерн використовує Uniswap, починаючи з v2.
Upgradability: коли потрібна і коли шкодить
UUPS (EIP-1822) vs Transparent Proxy (EIP-1967): вибір залежить від того, хто платить за апгрейд. У UUPS логіка апгрейду в імплементації — дешевше для користувачів, але якщо в новій імплементації прибрати функцію upgradeTo — протокол втрачає можливість апгрейду назавжди. У Transparent Proxy логіка в proxy — трохи дорожче кожен виклик, але надійніше.
Для протоколів з TVL понад $10M апгрейдабельність через multisig без timelock — це централізований вектор атаки. Gnosis Safe 4-of-7 + 48-годинний timelock через OpenZeppelin TimelockController — мінімальний стандарт довіри.
Tokenomics на рівні контракту
Ve-модель (vote-escrowed, як в Curve) вимагає careful balance: контракт блокує токени на строк до 4 років, нараховує voting power через balanceOfAtTime() на конкретний блок. Якщо voting power розраховується неправильно — governance атака коштує дешевше, ніж повинна.
Emission schedule повинен бути immutable або керуватися через governance з супер-мажоритарним голосуванням. Зміна емісії retroactively — це саме те, що вбиває довіру до протоколу.
Стек розробки
| Компонент | Інструменти | Призначення |
|---|---|---|
| Розробка | Foundry, Hardhat | Основне середовище, тести, деплой |
| Базові контракти | OpenZeppelin 5.x | Access control, proxy, tokens |
| Oracle | Chainlink, Uniswap v3 TWAP | Цінові дані |
| Тестування | Foundry fuzz, Echidna | Property-based тести |
| Статичний аналіз | Slither, Mythril | Автоматичний пошук вразливостей |
| Моніторинг | Tenderly, OpenZeppelin Defender | Алерти, автоматизація |
| Індексування | The Graph | Субграф для frontend |
Fork-тести на Foundry дозволяють запустити весь протокол проти реального стану mainnet: vm.createFork("mainnet"), vm.rollFork(blockNumber). Це єдиний спосіб перевірити взаємодію з реальними пулами Uniswap, реальними Chainlink feeds та реальними позиціями Aave.
Що входить в процес розробки?
-
Специфікація (1 тиждень). Формальний опис інваріантів: «сумарний борг завжди менший за сумарну заставу з урахуванням LTV», «тільки ліквідатор може закрити unhealthy позицію», «emission rate не може зрости більше ніж на X% за один governance цикл». Інваріанти стають основою для Echidna property-тестів.
-
Архітектурний дизайн (3-5 днів). Storage layout, інтерфейси, діаграма взаємодії контрактів. Рішення щодо апгрейдабельності та governance. Цей етап дешевше змінити на папері, ніж після 2 тижнів розробки.
-
Розробка (3-8 тижнів). Залежить від складності протоколу. Паралельно: контракти + тести в Foundry (покриття >90%), субграф на The Graph, скрипти деплою.
-
Внутрішній аудит + підготовка до зовнішнього. Slither CI на кожен PR. Перед зовнішнім аудитом — повна Mythril-перевірка, ручний review за SWC-checklist. Мета — закрити low/medium до зовнішнього аудитора, щоб він зосередився на високорівневих векторах.
-
Деплой. Testnet (Sepolia/Arbitrum Goerli) → staged mainnet через multisig з timelock → post-launch моніторинг через Tenderly.
Орієнтири за термінами
Мінімальний AMM-протокол (xy=k, без концентрованої ліквідності) — 4-6 тижнів. Лендинг за моделлю Compound v2 — 8-12 тижнів. Повноцінний протокол з ve-токеномікою, governance та cross-chain підтримкою — від 3 до 6 місяців. Зовнішній аудит займає 2-4 тижні додатково і планується заздалегідь у топових фірм.
Вартість розраховується після технічної специфікації. Отримайте консультацію — оцінимо ваш проект безкоштовно. Наш досвід: 10+ років у блокчейн-розробці, 50+ успішних проектів, сертифіковані аудитори.
Що входить в роботу
- Документація: специфікація інваріантів, архітектурна діаграма, технічна документація для аудитора.
- Доступи: репозиторій з вихідним кодом, звіти аудиту, скрипти деплою, адміністративний мультисиг-гаманець.
- Навчання: передача знань команді замовника щодо роботи з протоколом та моніторингу.
- Підтримка: 2 тижні post-launch підтримки, фіксація критичних багів у рамках warranty.
Додаткові заходи безпеки
Ми також рекомендуємо включати в контракти механізми pause та emergency shutdown, а також використовувати формальні верифікатори, такі як Certora, для доведення інваріантів. Наші протоколи проходять зовнішній аудит з мінімальною кількістю зауважень — в середньому не більше 2 medium-вразливостей.Замовте розробку DeFi-протоколу з перевіреною архітектурою. Якщо ви розробляєте DeFi-протокол, замовте аудит архітектури на ранньому етапі — це зекономить час і гроші. Зв'яжіться з нами — оцінимо ваш проект і запропонуємо оптимальну архітектуру.







