Проектування архітектури DeFi-протоколу
Команда приходить з ідеєю: «хочемо lending-протокол з yield farming та своїм токеном». Через два місяці розробки виясняється, що vault-контракт не може апгрейдитися без втрати state, токеномика створює інфляційну спіраль при першому unlock schedule, а оракул читає spot-ціну з пулу з $50k ліквідністю — маніпулюється однією транзакцією. Це вартість архітектурних рішень, прийнятих за 20 хвилин на початку проекту.
Проектування архітектури — це окрема фаза, результат якої документ: діаграми контрактів, storage layout, економічна модель з симуляціями, матриця ризиків. Потім уже код.
Що входить в архітектурне проектування
Токеномика: де ломаються більшість протоколів
Найчастіша помилка — emission schedule без врахування sell pressure. Протокол видає 1000 токенів на день як reward для LP-провайдерів. Якщо немає utility (чому тримати токен крім як для подальшого фарміну), всі награди негайно продаються. Ціна падає, APY у доларах падає, LP йдуть, ліквідність падає — death spiral.
Стійкі моделі будуються по-іншому: reward токен потрібен для доступу до протоколу (fee discount, governance weight, boosted yields через veToken модель). Curve Finance's veCRV — хрестоматійний приклад: щоб отримати максимальний boost, потрібно локувати CRV на строк до 4 років. Це створює органічний спрос та скорочує обращаємий supply.
При проектуванні будуємо Python-симуляцію emission vs. demand на 12-24 місяці вперед з кількома сценаріями (бичій ринок, ведмежий, флет). Результат — конкретні цифри: при якому обсязі TVL токен має позитивний тиск покупок.
Контрактна архітектура: модульність vs. складність
Монолітний контракт простіше аудировать, але не розширюваний. Diamond Pattern (EIP-2535) максимально гнучкий, але різко ускладняє аудит та створює ризики storage collision між facets. Правильний вибір залежить від roadmap.
Типові архітектурні паттерни:
| Паттерн | Коли використовувати | Ризики |
|---|---|---|
| Monolithic + UUPS | Простые протоколи, швидкий аудит | Лімit байткода 24 KB |
| Module system (Gnosis Safe style) | Розширюваність функціональності | Складність інтеграції модулів |
| Diamond (EIP-2535) | 10+ функціональних блоків | Storage collision, складний аудит |
| Immutable + migration | Максимальний trust, без апгрейдів | Неможливість виправлення багів |
| Proxy factory | Багато однотипних екземплярів | Clone initialization ризики |
Для DeFi-протоколів з TVL-ціллю >$1M рекомендуємо UUPS з namespaced storage (ERC-7201). Апгрейдаємість — необхідність на ранніх етапах (баги трапляються), але повинна бути захищена multisig з timelock: зміни вступають в силу через 48-72 години, спільнота може помітити та среагувати.
Управління ліквідністю
Protocol-owned liquidity (POL) vs. incentivized liquidity — фундаментальний вибір. Якщо протокол платить LP-провайдерам emissions, він арендує ліквідність. Стане платити перестати — ліквідність йде. OlympusDAO та Tokemak досліджували POL-моделі: протокол володіє власною ліквідністю та не залежить від mercenary capital.
Для AMM-протоколів критично: на якому DEX будувати ліквідність. Uniswap v3 concentrated liquidity дає кращу капітальну ефективність, але потребує активного менеджменту діапазонів. Curve v2 оптимален для коррельованих пар. Balancer weighted pools — для нестандартних ваг (80/20 vs. 50/50 знижує impermanent loss для governance токена).
Управління ризиками: матриця на старте
Перед написанням першої строки кода складаємо матрицю ризиків:
- Oracle risk: що відбудеться при маніпуляції ціною? Circuit breaker? Pausing?
- Liquidity risk: що при bank run (всі виводять одночасно)? Reserve factor?
- Smart contract risk: план дій при знайденій критичній уязвимості?
- Admin key risk: multisig, timelock, в майбутньому moving to DAO governance
- Regulatory risk: KYC/AML вимоги в цільових юрисдикціях
Як проходить проектування
Тиждень 1: аналітика та benchmarking. Розбираємо аналоги: Aave v3, Compound v3, Euler Finance, Morpho. Смотримо інциденти (rekt.news, immunefi post-mortems). Фіксуємо, що робимо інакше та чому.
Тиждень 2: архітектурний документ. Діаграми контрактів (Mermaid/draw.io), storage layout таблиці, інтерфейси (Solidity interface файли без реалізації). На цьому етапі проводимо internal review з питанням: «що сломається при кожному сценарії атаки».
Тиждень 3: економічна модель. Python-симуляція токеномики, stress tests TVL, breakeven аналіз по fee revenue. Результат — конкретні рекомендації по параметрам: collateral factor, fee rate, emission schedule.
Витоги: технічний документ 30-50 сторінок + Solidity інтерфейси + симуляційні скрипти. Це вхідний матеріал для розробки та аудиту.
Типові помилки, які виявляємо на етапі проектування
Circular dependency у контрактах. A викликає B, B викликає A. При reentrancy атаці це стає нескінченним рекурсивним викликом. Видно на діаграмі залежностей до написання коду.
Недооцінка gas cost governance операцій. Якщо vote за proposal стоїть $50 в газі, ніхто не голосує. Потрібен або gasless voting (EIP-712 signatures + relayer), або snapshot off-chain + on-chain execution через multisig.
Неправильний порядок операцій у multi-step flows. Класика: спочатку transfer токена, потім перевірка allowance. Повинно бути навпаки. На sequence diagram це видно.
Відсутність pause механізму. При виявленні критичної уязвимості потрібно зупинити протокол за секунди. Pausable контракт з multisig як guardian — стандарт. Без цього єдиний варіант — чекати governance vote 48 годин, поки дренуються кошти.
Часові орієнтири
Архітектурне проектування для протоколу середної складності — 2-3 тижні. Результат: документація, інтерфейси, симуляції. Цей етап скорочує час розробки на 30-40% та вартість аудиту — тому що аудитори працюють по документації, а не розбираються в коді з нуля.
Вартість розраховується індивідуально.