Aave V4: От разрозненного рынка к модульной ликвидности

Автор: Tia, Techub News

В области DeFi-кредитования Aave традиционно служит ориентиром инноваций и отраслевых стандартов. С ростом числа пользователей и разнообразия активов, в Aave V3 начали проявляться такие проблемы, как разрыв ликвидности, неотлаженные механизмы управления рисками и принципы ликвидации. Для решения этих задач V4 был системно переосмыслен и обновлён: структура ликвидности была переработана в единую Hub и модульную Spoke архитектуру, что позволяет совместно использовать ликвидность для нескольких активов и стратегий при сохранении изоляции рисков; система учёта была обновлена до модели долей в стиле ERC-4626, обеспечивая ясность и контроль глобального состояния ликвидности; механизмы ликвидации перешли от фиксированных пропорций к динамическим, основанным на health factor, с минимально необходимым уровнем ликвидации. В целом V4 — это не просто оптимизация параметров, а эволюция архитектуры и механизмов, которая превращает Aave из разрозненного многомаркетного кредитного протокола в модульную инфраструктуру с расширяемостью, высокой капитализацией и управляемыми рисками.

От «рынка» к реальности разрыва ликвидности в V3

В Aave V3 протокол использовал «централизованный» подход к развертыванию в виде «рынков». На разных сетях, а иногда и внутри одной, создавались независимые рынки, например, в основном сетевом Ethereum — Core и Prime. Каждый рынок имел свой собственный пул ликвидности, набор поддерживаемых активов и риск-параметры, формируя собственный профиль риска.

Когда пользователь вносил активы в Aave V3, он делал это конкретно на определённый рынок, а не в глобальный общий пул. Это означало, что активы, внесённые в рынок Ethereum Core, могли использоваться только его заемщиками, и не могли быть вызваны пользователями Prime или других сетей.

Такая структура обеспечивает очевидные преимущества в изоляции рисков: риски не передаются между рынками. Но есть и очевидный минус: ликвидность разрезана. Даже один и тот же актив может находиться одновременно в нескольких рынках, что усложняет его управление, снижает эффективность использования капитала, глубину рынка и возможности расширения новых функций.

Hub и Spoke: логика реструктуризации ликвидности в Aave V4

Ответом на эту проблему стала кардинальная переработка базовой архитектуры с введением новой схемы — Hub and Spoke (лучевая). Эта идея направлена на решение проблем разрыва ликвидности и ограниченности масштабируемости, присутствовавших в V3.

В V4 протокол больше не связывает ликвидность с отдельными рынками. Вместо этого на каждой сети создаётся единый централизованный узел ликвидности — Hub, который является основой для всех средств. Активы, предоставляемые пользователями, не попадают в конкретный рынок, а поступают в Hub, который управляет глобальной ликвидностью и основными учётными ограничениями: например, он следит за тем, чтобы сумма выданных активов не превышала объём внесённых, и фиксирует использование ликвидности по различным модулям.

Но Hub сам по себе не взаимодействует напрямую с пользователями. Взаимодействие происходит через слой модульных элементов — Spoke, которые в V4 называют «лучами».

Spoke: модульный вход с локализованными рисками

Spoke формирует фронт-план взаимодействия пользователя с протоколом. Каждый Spoke подключён к одному Hub, но может иметь свои уникальные правила, параметры и гипотезы по рискам. В нём управляются пользовательские позиции, структура залогов, подключаются оракулы и реализуются механизмы ликвидации, в то время как Hub обеспечивает только контроль лимитов ликвидности и учёт.

Ключевая идея — риски строго локализованы внутри Spoke и не распространяются по всей системе. Разные типы активов и модели заемных требований могут реализовываться независимо, при этом общий пул ликвидности остаётся общим, а риск изолирован.

Благодаря этому многие функции, реализованные в V3 и казавшиеся громоздкими, в V4 можно реализовать более естественно. Например, режим E-Mode больше не является просто набором параметров, а может выступать отдельным Spoke, обслуживающим специально связанные активы. Аналогично, изоляционные режимы могут реализовываться через отдельные Spoke с назначением лимитов по ликвидности. Для RWA или более сложных залоговых структур V4 позволяет внедрять кастомные Spoke с расширенными правилами доступа и рисками, не усложняя весь протокол.

Единая учётная запись ликвидности V4: как она считается?

Для поддержки единого централизованного управления ликвидностью в Hub в V4 отказались от модели aToken rebase и перешли к системе долей ERC-4626.

В Aave V4 протокол отказался от перерасчёта aToken, использовав вместо этого модель учёта в стиле ERC-4626. Пользователи теперь держат фиксированное количество долей (shares), а их ценность меняется со временем, отражая доходность. Иными словами, доходность больше не отображается изменением количества токенов, а через изменение стоимости каждой доли, что ближе к традиционным хранилищам (vault).

Эта модель тесно связана с концепцией единой ликвидности. В V4 все депозиты собираются в Hub, который использует доли для точного учёта общего состояния активов. Hub не занимается управлением стратегиями или рисками каждого Spoke отдельно, а лишь следит за общим объёмом активов, количеством долей и лимитами по модулям. Такой подход позволяет одновременно делить активы между несколькими Spoke, сохраняя прозрачность и контроль, избегая сложностей и рисков, связанных с rebase aToken в мульти-модульной среде.

Если бы использовался классический rebase aToken, то деление активов между Spoke создаст сложности с синхронизацией, рисками внешних сбоев и ограничениями по лимитам. Модель ERC-4626 превращает эти проблемы в простую арифметику, позволяя Hub безопасно и эффективно поддерживать разные стратегии и настройки рисков, повышая капвую эффективность и создавая основу для модульной архитектуры V4 и будущего расширения.

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

Помимо реструктуризации ликвидности, V4 также внес изменения в механизмы ликвидации. В отличие от фиксированных пропорций, V4 вводит риск-ориентированный механизм ликвидации.

В V3 и ранних версиях, когда health factor позиции падал ниже порогового значения, разрешалась ликвидация с погашением части долга по заранее установленному close factor, с конфискацией залога. Этот подход был эффективен для защиты протокола, но при резких колебаниях или рисковых ситуациях мог приводить к чрезмерной ликвидации — масштабам, превышающим необходимость.

V4 сосредоточилась на «минимальной необходимой ликвидации», то есть системе, которая оценивает, сколько долга и залога нужно ликвидировать, чтобы восстановить безопасный уровень health factor. Ликвидация больше не преследует цель максимизировать риск или сразу полностью очистить позицию, а стремится минимизировать ущерб пользователю и протоколу, сохраняя безопасность.

Это означает, что close factor стал динамическим, зависящим от текущей ситуации с рисками позиции. Размер ликвидации будет меняться в зависимости от волатильности активов, структуры залога и рисковых параметров, что делает механизм более реалистичным и снижает риск чрезмерных сбоев и нежелательных распродаж.

Обновление механизма ликвидации в Aave можно сравнить с концепцией Fluid. В отличие от классической модели «один размер подходит всем», V4 значительно улучшил точность и гибкость этой части протокола.

Однако по сравнению с Fluid, который интегрирует залоги непосредственно в торговую ликвидность и допускает автоматическое поглощение части рисков внутри пула, Aave остается в другой парадигме. В Fluid риск частично поглощается внутри пула, что позволяет избегать внешних ликвидаторов, снижая издержки и повышая эффективность. В Aave же, несмотря на более тонкую настройку ликвидационных правил, всё равно требуется внешняя ликвидация, и она не может полностью интегрироваться с пулом без внешних участников.

Общий вывод

В целом, Aave V4 — это не кардинальный слом существующих моделей, а осторожная, но системная эволюция: переосмысление и реструктуризация ликвидности через архитектуру Hub and Spoke, локализация рисков в модулях Spoke и внедрение более точных механизмов ликвидации. Всё это превращает протокол из разрозненного многомаркетного кредитного сервиса в модульную, расширяемую платформу для сложных финансовых структур.