DeFi — техническая архитектура протоколов

DeFi (децентрализованные финансы) на техническом уровне — это не один протокол, а целый стек компонентов:

  • базовая сеть (Ethereum, Solana, TON, L2);
  • смарт-контракты протоколов (DEX, лендинг, стейкинг);
  • слой ликвидности (пулы, рынки кредитования, стейблкоины);
  • инфраструктура данных (оракулы, индексеры, аналитика);
  • кросс-чейн-связки (мосты, wrapped-активы);
  • слой исполнения и упорядочивания транзакций (мемпул, MEV-инфраструктура, боты).

Общий обзор DeFi как явления см. на DeFi (обзор и направления). На этой странице — техническая архитектура: как устроены протоколы под капотом, за счёт чего они работают и где находятся «ломкие» места.

DeFi — техническая архитектура протоколов

Техническая архитектура DeFi: полный обзор компонентов и их взаимодействия

Удобно представлять DeFi как несколько слоёв:

  • Сеть и исполнение контрактов.

Базовый блокчейн (L1 или L2) и его виртуальная машина, где исполняются смарт-контракты (EVM, SVM и др.).

  • Протоколы и контракты.

Логика DEX (децентрализованных бирж), AMM-пулы (DEX/AMM), кредитование, стейкинг (Стейкинг (staking): как он работает в PoS-сетях, виды, доходность и риски), yield farming и т.п.

  • Ликвидность и позиции пользователей.

Пулы, депозиты, залоги, стейк, LP-токены. Всё это живёт в состоянии контрактов и влияет на метрики вроде ликвидности и TVL.

  • Инфраструктура данных.

Оракулы цен и индексов, индексеры, аналитика, сервисы мониторинга (например, DeFiLlama).

  • Кросс-чейн-компонент.

Мосты, wrapped-активы, омничейн-роутеры, которые связывают ликвидность между сетями.

  • MEV и порядок транзакций.

Мемпулы, бандлеры, блок-билдеры и боты, которые влияют на то, в каком порядке ваши транзакции попадут в блок (и по какой цене исполнится своп).

Каждый слой добавляет функциональность, но и расширяет поверхность атаки.

Базовый слой: сети и виртуальные машины

DeFi-протокол не существует в вакууме — он работает в конкретной сети:

  • Ethereum и EVM-совместимые L1/L2 (Arbitrum, Optimism и др.) — основной центр DeFi, множество протоколов и инструментария.
  • Сети с собственной VM: Solana (SVM), другие высокопроизводительные L1.
  • TON, где DeFi интегрируется с ботами, кошельками и сервисами экосистемы.

Ключевые элементы базового слоя:

  • Виртуальная машина (VM).

Определяет, как исполняется код смарт-контрактов, какие есть ограничения по газу, какие типы данных доступны.

  • Модель аккаунтов.

EOA/контракты в EVM-сетях, модель програмируемых аккаунтов и т.п.

  • Система комиссий.

Как считается газ, есть ли EIP-1559-подобная динамика, как меняется стоимость транзакций в пике нагрузки.

  • Консенсус и безопасность.

PoS-механизмы, валидаторы, стейкинг — фундаментальный слой, описанный на странице о стейкинге.

От того, как устроен базовый слой, зависят:

  • стоимость операций DeFi;
  • предсказуемость задержек;
  • возможности для MEV (например, публичный или частичный мемпул).

Смарт-контракты и «ликвидность как код»

Ядро DeFi — смарт-контракты, в которых зашита логика протокола. Общие основы см. на странице о смарт-контрактах, здесь — особенности именно DeFi.

Основные типы контрактов в DeFi:

  • Контракты пулов ликвидности.

Хранят резервы токенов, реализуют формулы ценообразования (x·y=k, stableswap, концентрированная ликвидность и др.), учитывают долю LP и комиссии.

  • Контракты кредитования.

Ведут учёт залогов и долгов, лимитов LTV, ставок, уровней ликвидации.

  • Контракты стейкинга и распределения наград.

Запоминают, кто и сколько застейкал, рассчитывают награды, реализуют период блокировки и правила анстейка.

  • Контракты управления (governance).

DAO-голосования, timelock-контракты, трезори.

  • Роутеры и фасады.

Поверх базовых контрактов часто существуют «роутеры», которые:

  • упрощают UX (одна функция — несколько шагов под капотом);
  • добавляют защиту от ошибок пользователя;
  • реализуют маршрутизацию свопов через несколько пулов.

Принципы:

  • Состояние протокола — это состояние контрактов (балансы токенов, данные о залогах, параметрах).
  • Права доступа контролируются ролями:
    • owner, admin, DAO, multisig — кто может менять параметры;
    • emergency-функции (pause, shutdown) на случай инцидентов.

Из архитектуры контрактов вытекают многие риски: от классической reentrancy-уязвимости до логических ошибок в риск-моделях.

Оракулы и внешний мир

Большинство DeFi-протоколов не могут жить в полностью «замкнутом» мире — им нужны:

  • рыночные цены активов;
  • индексы (ставки, волатильность, индексы реальных активов);
  • иногда — данные из Web2.

Этим занимается слой оракулов:

  • контракты-провайдеры цен (Chainlink, Pyth, собственные фиды протоколов);
  • схемы агрегации: медиана по нескольким источникам, VWAP и др.;
  • частота обновления и механизмы защиты от фид-манипуляций.

Оракулы особенно критичны для:

  • кредитных рынков (определение стоимости залогов и триггеры ликвидаций);
  • деривативов и синтетики;
  • стейблкоинов и криптозалоговых моделей.

Типичные проблемы:

  • запоздалые обновления цен в моменты сильной волатильности;
  • зависимость от одного поставщика данных;
  • атаки через тонкие пулы и манипуляцию ончейн-ценой.

Мосты и кросс-чейн DeFi

DeFi всё чаще живёт не в одной сети, а в нескольких. Логика протокола и ликвидность могут быть распределены по:

  • L1 и L2 внутри одного стека (Ethereum + rollups);
  • нескольким независимым сетям (Solana, TON и др.);
  • специализированным чейнам внутри экосистем (Cosmos-зоны и пр.).

Связующим звеном выступают кросс-чейн-мосты и омничейн-протоколы:

  • Lock and mint / burn and release.

Актив блокируется в одной сети, в другой выпускается wrapped-версия; при обратной операции wrapped сжигается, оригинал разблокируется.

  • Light client-мосты.

Используют упрощённые клиенты цепей для проверки доказательств.

  • Мосты через доверенных валидаторов.

Небольшая группа нод подписывает события, выступая как «кастодиан» для блокированных активов.

Поверх мостов строятся:

  • мультичейн-DEX и роутеры;
  • кросс-чейн-пулы ликвидности;
  • омничейн-стейблкоины.

Но мосты — один из самых рискованных элементов архитектуры. Типовые риски и кейсы рассматриваются на странице о рисках мостов.

Инфраструктура: индексеры, аналитика, агрегаторы

Поверх базовых контрактов и мостов работает инфраструктурный слой:

  • Индексеры и API.

Сервисы, которые:

  • читают события контрактов;
  • агрегируют их в удобные представления (позиции пользователей, историю ликвидаций, состояние пулов);
  • предоставляют API для фронтендов и аналитики.
  • Агрегаторы DEX и маршрутизаторы свопов.

Сервисы/контракты, которые выбирают лучший маршрут обмена через несколько DEX и сетей:

  • оценивают ликвидность и slippage;
  • учитывают комиссии сети;
  • иногда разбивают сделку на несколько частей.
  • Панели мониторинга и аналитика.

DeFiLlama, Dune, внутренние дашборды протоколов:

  • показывают TVL по пулам;
  • раскладывают ликвидность по активам и сетям;
  • позволяют оценить устойчивость протокола.

Фронтенды DeFi-протоколов почти всегда опираются на индексеры и агрегаторы, чтобы не доверять только «сырым» запросам к RPC.

MEV и порядок транзакций

MEV (Maximal / Miner / Maximal Extractable Value, см. MEV (Maximal Extractable Value) в блокчейнах и на Solana — определение и примеры) — это дополнительная ценность, которую можно извлечь из упорядочивания транзакций в блоке:

  • вставить свою транзакцию перед/после чужой;
  • заменить чужую транзакцию на свою;
  • собрать связку транзакций в выгодной последовательности.

В DeFi MEV связан с:

  • DEX и AMM-пулами (sandwich-атаки, арбитраж, JIT-ликвидность);
  • ликвидациями в кредитных протоколах;
  • обновлением оракулов и ребалансировкой стратегий.

Технически слой MEV включает:

  • публичный и приватный мемпул (relay-сети, bundler-сервисы);
  • searcher-ботов, которые генерируют выгодные бандлы;
  • builder-инфраструктуру (в Ethereum — PBS, relays, блок-билдеры).

Особенности:

  • протоколы часто вынуждены учитывать MEV при дизайне (например, использовать TWAP-цены, лимитные ордера, механизмы защиты от sandwich);
  • часть MEV пытаются «социализировать», распределяя доход между стейкерами/валидаторами и протоколами (MEV-share).

MEV — это не отдельный протокол, а следствие архитектуры сетей и открытого мемпула.

Поверхность атаки и типовые риски архитектуры DeFi

Чем более компонуемым становится DeFi, тем больше мест, где что-то может пойти не так.

Основные технические риски, связанные с архитектурой:

  • Контракты.

Ошибки логики, reentrancy, неверные проверки, неограниченные разрешения, неаккуратные апгрейды.

  • Оракулы.

Манипуляция ценой через тонкие пулы, задержки обновлений, зависимость от одного провайдера.

  • Мосты.

Взломы мультисигов, ошибки в проверке доказательств, компрометация валидаторов — см. Риски мостов (Bridge Risks): таксономия угроз, контроль и чек-листы.

  • Композиция протоколов.

Цепочки «протокол A → протокол B → протокол C»:

  • ошибки в одном звене передаются вверх по цепочке;
  • сложнее оценить совокупный риск для пользователя.
  • MEV и порядок транзакций.

Sandwich-атаки, фронт-ран, конкуренция ликвидаторов. Протокол может быть формально «корректным», но пользователь фактически получает резко худшую цену из-за порядка исполнения.

  • UX-слой.

Фишинговые фронтенды, подмена адресов контрактов, опасные разрешения в кошельке.

Общие подходы к управлению рисками описаны на странице про риск-менеджмент и в разделе безопасность и риски.

Как проектируют архитектуру DeFi-протоколов

На практике дизайн DeFi-протокола — это баланс между:

  • Функциональностью.

Какие сценарии должен поддерживать протокол:

  • базовые обмены;
  • кредитование и плечо;
  • стейкинг, LST и yield farming;
  • кросс-чейн-операции.
  • Безопасностью.

Ограничение прав админов, timelock для важных операций, механизмы emergency-pause, модели bug bounty и аудитов.

  • Композиционностью.

Насколько легко протокол можно использовать как «кирпич» в других стратегиях:

  • понятные стандарты токенов и интерфейсов;
  • предсказуемые инварианты (например, у AMM-пулов).
  • Оптимизацией газа и UX.

Минимизация количества вызовов, объединение популярных действий (например, «approve+swap»), интеграция с популярными кошельками и агрегаторами.

Типичный путь:

  • прототип контракта и экономической модели на тестовой сети;
  • внутренние ревью и формальные проверки инвариантов;
  • независимые аудиты;
  • постепенное увеличение лимитов (caps), а не сразу «максимальный TVL»;
  • наблюдение за поведением протокола и метриками (объёмы, ликвидность, инциденты).

Для пользователей важны не только «фичи», но и то, как протокол устроен внутри: прозрачная архитектура проще для анализа и, как правило, устойчивее к неожиданным эффектам.

FAQ

Какие виртуальные машины используются в DeFi? EVM (Ethereum), SVM (Solana), TVM (TON) и другие. Каждая определяет возможности смарт-контрактов и стоимость операций.

Чем отличается архитектура L1 и L2 DeFi протоколов? L2 (Arbitrum, Optimism) наследуют безопасность L1, но предлагают более низкие комиссии и могут иметь специфические оптимизации.

Как оракулы интегрируются в архитектуру DeFi? Через смарт-контракты, которые запрашивают или получают обновления данных от провайдеров оракулов для ценообразования и ликвидаций.

Что такое композиционность в архитектуре DeFi? Возможность протоколов работать вместе как «лего» - когда один протокол использует функции другого в своих операциях.

Как MEV влияет на архитектуру протоколов? Протоколы вынуждены добавлять защитные механизмы: TWAP-цены, лимитные ордера, MEV-защиту в UX слое.

См. также

Task Runner