Розробка DeFi-протоколу з аудитом та gas-оптимізацією

Розробка 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 для автоматичного перемикання джерел при збоях.

Архітектура протоколу

Модульна структура контрактів

Монолітний контракт на 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 — це саме те, що вбиває довіру до протоколу.

Стек розробки

Fork-тести на Foundry дозволяють запустити весь протокол проти реального стану mainnet: vm.createFork("mainnet"), vm.rollFork(blockNumber). Це єдиний спосіб перевірити взаємодію з реальними пулами Uniswap, реальними Chainlink feeds та реальними позиціями Aave.

Що входить в процес розробки?

1. Специфікація (1 тиждень). Формальний опис інваріантів: «сумарний борг завжди менший за сумарну заставу з урахуванням LTV», «тільки ліквідатор може закрити unhealthy позицію», «emission rate не може зрости більше ніж на X% за один governance цикл». Інваріанти стають основою для Echidna property-тестів.

2. Архітектурний дизайн (3-5 днів). Storage layout, інтерфейси, діаграма взаємодії контрактів. Рішення щодо апгрейдабельності та governance. Цей етап дешевше змінити на папері, ніж після 2 тижнів розробки.

3. Розробка (3-8 тижнів). Залежить від складності протоколу. Паралельно: контракти + тести в Foundry (покриття >90%), субграф на The Graph, скрипти деплою.

4. Внутрішній аудит + підготовка до зовнішнього. Slither CI на кожен PR. Перед зовнішнім аудитом — повна Mythril-перевірка, ручний review за SWC-checklist. Мета — закрити low/medium до зовнішнього аудитора, щоб він зосередився на високорівневих векторах.

5. Деплой. 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.

Замовте розробку DeFi-протоколу з перевіреною архітектурою. Якщо ви розробляєте DeFi-протокол, замовте аудит архітектури на ранньому етапі — це зекономить час і гроші. Зв'яжіться з нами — оцінимо ваш проект і запропонуємо оптимальну архітектуру.