Проектирование архитектуры 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 | Простые протоколы, быстрый аудит | Лимит байткода 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 часа, community может заметить и среагировать.
Управление ликвидностью
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, eventually 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 analysis по fee revenue. Результат — конкретные рекомендации по параметрам: collateral factor, fee rate, emission schedule.
Итог: технический документ 30-50 страниц + Solidity интерфейсы + симуляционные скрипты. Это входной материал для разработки и аудита.
Типичные ошибки, которые выявляем на этапе проектирования
Circular dependency в контрактах. A вызывает B, B вызывает A. При reentrancy атаке это становится бесконечным рекурсивным вызовом. Выявляется на диаграмме зависимостей до написания кода.
Недооценка gas cost governance операций. Если vote за proposal стоит $50 в gas, никто не голосует. Нужен либо 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% и стоимость аудита — потому что аудиторы работают по документации, а не разбираются в коде с нуля.
Стоимость рассчитывается индивидуально.