Розробка протоколу стейблкоїну стилю MakerDAO
У березні 2020 року, "Чорний четвер" у MakerDAO: ETH впав на 50% за кілька годин. Цінові оракули запізнилися через перевантаженість мережі. Боти ліквідації не встигали через високу вартість газу. Деякі позиції Vault перейшли в ліквідацію з нульовою ціною — ліквідатори захопили залог ETH практично безпомощно. Протокол отримав дефіцит в $5,4 млн, який пізніше покрили через аукціони розведення MKR. Це не був баг у коді — це була системна відмова механіки.
Розробка протоколу CDP починається з розуміння цих механік, а не написання контрактів.
Архітектура протоколу CDP
Ядро: три інваріанти системи
Будь-який протокол подібний до MakerDAO побудований навколо трьох інваріантів, порушення кожного з яких призводить до системної неплатоспроможності:
- Надлишкова забезпеченість: загальна вартість забезпечення > загальний борг у стейблкоїні
- Цілісність цінового каналу: дані про ціни мають бути актуальними і стійкими до маніпуляцій
- Платоспроможність ліквідації: під час ліквідації протокол завжди отримує більше, ніж втрачає
Ці інваріанти перекладаються в конкретні параметри: коефіцієнт ліквідації (мінімальне забезпечення, зазвичай 130-175%), збір стабільності (річна ставка на борг), штраф за ліквідацію (бонус ліквідатора, 10-15%), ліміт боргу (максимальний борг за типом забезпечення).
Модульна архітектура: MakerDAO проти монолітності
MakerDAO використовує надзвичайно модульну архітектуру: окремі контракти для Vat (основний облік), Cat (ліквідація), Dog (ліквідація v2), Jug (збір стабільності), Spot (канал ціни), Flip/Clip (аукціони). Це дозволяє замінювати модулі без повного оновлення, але створює складність під час розробки та аудиту.
Для нового протоколу з нуля ми рекомендуємо менш агресивну модульність: 3-4 контракти замість 12+. Основний контракт із логікою CDP, окремий модуль оракула, окремий модуль аукціону. Оновлюваність UUPS через OpenZeppelin — дозволяє виправляти помилки без втрати стану.
Критичні компоненти: детальний розбір
Цінові оракули та захист від маніпуляцій
Це найслабше місце в більшості протоколів CDP. Кілька векторів атак:
Маніпуляція spot ціною через flash loan. Якщо протокол використовує spot ціну з пула Uniswap без TWAP, зловмисник робить великий своп, різко змінює ціну забезпечення, відкриває або ліквідує позиції на вигідних умовах, повертає своп в одній транзакції. Рішення: TWAP з мінімальним періодом 30 хвилин перед активацією ліквідації.
Застарілість цінового каналу Chainlink. Chainlink оновлює ціну при відхиленні >0,5% або через heartbeat (1-24 години залежно від мережі та каналу). Під час екстремальної волатильності heartbeat може відставати. Обов'язкова перевірка: require(block.timestamp - updatedAt < maxStaleness). Установіть maxStaleness на 1-3 години для основних активів, 30 хвилин для нестійких.
Відсічний вимикач. При аномальній зміні ціни (>20% в одному оновленні), модуль ціни зморожує ліквідації на N хвилин. Це відтворює OSM (Oracle Security Module) MakerDAO: ціна застосовується з затримкою в 1 годину, надаючи час на реакцію при атаці на оракул.
Наш стандартний модуль оракула поєднує основний канал Chainlink + Uniswap v3 TWAP як вторинний, з логікою fallback та відсічним вимикачем. Якщо відхилення між джерелами перевищує 5% — ліквідації блокуються.
Механізм аукціону ліквідації
MakerDAO еволюціонував від англійського аукціону (Flip) до голландського аукціону (Clip, DAI 2.0). Голландський аукціон краще підходить для DeFi:
- Ціна починається високо (вище ринкової ціни забезпечення) і зменшується за формулою до мінімуму
- Будь-який учасник може взяти частину або весь лот у будь-який момент аукціону
- Якщо ціна падає нижче мінімуму, кредитор протоколу (buffer надлишку) покриває різницю
- Flash loan дружба: купити забезпечення, негайно продати на DEX, повернути стейблкоїн в одній транзакції
Параметри голландського аукціону:
-
buf— початковий множник ціни (зазвичай 1,2x цена оракула) -
tail— максимальна тривалість аукціону (наприклад, 3600 секунд) -
cusp— мінімальний відсоток від стартової ціни (наприклад, 0,4 = 40%) -
chip/tip— винагорода за ініціювання аукціону (стимул для ботів)
Без tip ліквідаційні боти не будуть ініціювати аукціони на малі позиції — вартість газу перевищує потенційний прибуток. Чорний четвер частково через це: немає стимулу запускати аукціони при високому газі.
Збір стабільності та механізм погашення боргу
Збір стабільності нараховується безперервно через глобальний накопичувач rate (аналогічний chi MakerDAO). Кожну секунду всі відкриті позиції зростають на (1 + annualRate)^(1/31536000) - 1. Оновлення накопичувача ліниве: перераховується при кожному доступі до позиції, не у кожному блоці.
Накопичені збори надходять у buffer надлишку. Коли надлишок перевищує поріг, надлишок перенаправляється на викупку та спалювання токена управління. Дефіцит буфера надлишку (як у Чорному четвергу) покривається через аукціон боргу: протокол чеканить токени управління та продає їх за стейблкоїн.
Це повна система: CDP → збір стабільності → buffer надлишку → викупка АБО аукціон боргу при дефіциті. Розробка та тестування всього ланцюга є ключовим.
Управління та параметри
Протокол CDP без управління є либо централізованим (власник змінює параметри), або статичним (hardcoded параметри). Для серйозного протоколу потрібно управління в ланцюзі з timelock:
- Пропозиції з мінімальним кворумом (наприклад, 4% від обігового пропозиції)
- Timelock 48-72 години перед виконанням будь-яких змін параметрів
- Аварійний multisig для критичних ситуацій (5/9 multisig, обхід timelock тільки для заморозки)
OpenZeppelin Governor + TimelockController є стандартною основою. Кастомізуйте для своєї токеноміки.
Процес розробки
Специфікація (1-2 тижні). Параметри забезпечення, структура зборів, механізм аукціону, управління. Все це повинно бути зафіксовано перед написанням коду. Зміна механізму аукціону після аудиту вимагає нового аудиту.
Розробка (3-8 тижнів). Контракти Solidity, тести Foundry. Обов'язково: fuzz тести на інваріанти (надлишкова забезпеченість, платоспроможність аукціону), fork тести з реальними даними каналів Chainlink, симуляція сценарію Чорного четвергу через vm.warp + різке змінення ціни оракула.
Аудит (4-8 тижнів). Для протоколів з потенційним TVL >$1M — один аудит є обов'язковим. Для TVL >$10M — два незалежних аудити. Типові результати аудиту протоколів CDP: неправильна обробка токенів з комісією як забезпечення, reentrancy у callback аукціону, неправильний розрахунок при частковому погашенні боргу.
Bug bounty і поступове запуск. Початковий ліміт боргу є мінімальним, зростає під час тестування протоколу в реальних умовах.
Оцінки за часом
MVP з одним типом забезпечення та базовими аукціонами — 4-6 тижнів розробки. Повноцінний протокол з кількома типами забезпечення, голландськими аукціонами, управлінням та інфраструктурою моніторингу — 2-3 місяці. Аудити не включені в ці часові рамки — планруйте окремо.
Вартість залежить від набору забезпечення, складності управління та вимог до UI.