Заимствование Ethereum: сравнение эволюции архитектуры MakerDAO, Yield, Aave, Compound и Euler

Заимствование является краеугольным камнем блокчейн-приложений на базе Ethereum . С миллиарды активов, выданных взаймы Понимание того, как работает заимствование, имеет решающее значение для разработчиков, архитекторов и исследователей.

Подобно эволюции парадигм программирования, эти приложения DeFi имеют разнообразные архитектурные конструкции, отражающие меняющиеся приоритеты, которые варьируются от безопасности до эффективности и удобства пользователей.

В этом анализе рассматривается архитектура таких приложений, как МейкерДАО , Сложный , Ааве , Эйлер , и Урожай . Мы выделим ключевые инновации и шаблоны проектирования, которые станут важными уроками для разработки будущих кредитных приложений.

Если вы разработчик, архитектор или исследователь безопасности, эта статья для вас. К концу вы легко поймете новые приложения для заимствований на Ethereum, быстро и всесторонне поймете их архитектуру. Погрузитесь, чтобы увидеть, как эти гиганты DeFi создаются с нуля.

Заимствование в DeFi

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

Однако есть одна загвоздка.

Стоимость залога всегда должна превышать стоимость кредита на заранее определенную величину .

Если стоимость залога падает ниже этой суммы, кредит ликвидирован .

Во время ликвидации кто-то другой погашает часть или всю вашу ссуду и получает взамен часть или все ваше обеспечение.

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

• Казначейство для хранения залогового обеспечения пользователей и заемных активов.
• Система бухгалтерского учета, которая отслеживает залог и задолженность каждого пользователя.
• Функции, определяющие процентную ставку заемщиков
• Механизм проверки наличия достаточного обеспечения кредита, обычно с использованием внешних ценовых оракулов.
• Путь ликвидации недостаточно обеспеченных кредитов
• Системы управления рисками, которые фиксируют общие суммы заимствований и другие показатели безопасности, такие как глобальные лимиты заимствований и лимиты заимствования для каждого пользователя, минимальные размеры залога и конкретные коэффициенты избыточного обеспечения.
• Интерфейс, позволяющий пользователям добавлять и удалять залоговое обеспечение, брать взаймы и погашать базовый актив.
  

Заимствование и кредитование можно рассматривать как отдельные функции. В DeFi мы находим обе функции в большинстве приложений для заимствований, но они не всегда хорошо интегрированы .

В Compound, Aave и Euler они есть . Процентные ставки для заемщиков и кредиторов внутренне коррелируют; на самом деле именно это позволяет этим приложениям работать с минимальным вмешательством.

С другой стороны, MakerDAO и Yield являются создателями активов, которые они кредитуют заемщикам.

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

В этой статье основное внимание будет уделено онлайн-заимствованиям и в значительной степени проигнорировано кредитование. Заимствование намного сложнее из-за требований обеспечения, а понимание схемы заимствования обычно позволяет лучше понять весь протокол.

Архитектурная эволюция MakerDAO

МейкерДАО , древний с точки зрения Эфириума, был запущен в нынешнем виде в ноябре 2019 года , и это держится 4,95 миллиарда долларов в качестве залога . Несмотря на модульную архитектуру с отдельными контрактами для каждой функции и уникальной терминологией, ее по-прежнему легко понять и проверить.

Функция казначейства в MakerDAO управляется Присоединиться контракты.

Eсть отдельный контракт за каждый токен, утвержденный в качестве залогового актива.

Напротив, у MakerDAO нет DAI, актива-заемщика.

Вместо этого это просто мята и ожоги DAI как требуется.

Бухгалтерский учет ведется в рамках НДС .sol договор. Объединения обновить этот контракт когда обеспечение поступает в систему или выходит из нее. Если пользователь берет взаймы, он напрямую взаимодействовать с контрактом vat.sol .

Это действие обновляет долговой баланс пользователя и позволяет ему создавать DAI при присоединении к DAI.

Чтобы погасить долг, пользователи записывают DAI в DAI Join. Затем этот процесс обновляет НДС, позволяя пользователю погасить свой кредит .

Кроме того, контракт vat.sol служит управление рисками двигатель. Он поддерживает глобальные лимиты заимствований, устанавливает минимальные пороговые значения для каждого пользователя и контролирует коэффициенты обеспечения.

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

Они относятся к процентной ставке, основанной на используемом залоге и преобладающем соотношении цен DAI и залога. Интересно, что эти значения передаются в контракт vat.sol другими контрактами MakerDAO, и этот метод отличается от большинства других приложений.

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

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

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

Основные моменты:

• Каждый актив имеет свой контракт в функции казначейства с максимальным распространением.
• Функция бухгалтерского учета централизована в рамках единого контракта, который также документирует и обеспечивает соблюдение параметров риска, включая проверки обеспечения.
• В отличие от других приложений, оракулы обновляют контракт, контролируя обеспечение.
• Оракулы цен и процентных ставок используют разные интерфейсы.
• Процентная ставка возникает извне
• Чтобы получить кредит, пользователи должны взаимодействовать с несколькими контрактами.

Архитектурная эволюция протокола доходности

Доходность v1 послужил доказательством концепции фиксированных ставок с использованием ДоходностьПространство . В этой версии механизм обеспеченного долга построен на базе MakerDAO. Однако Yield v1 был дорогостоящим в использовании и сложным в дополнении новыми функциями.

Осознав потенциал YieldSpace, мы быстро перешли к разработке Доходность v2 . Все еще черпаю вдохновение из MakerDAO, но теперь полностью независима, Yield v2. запущен в октябре 2021 г. ; В версии Yield v2 приоритет отдается снижению затрат на газ и улучшению пользовательского опыта.

Все проверки бухгалтерского учета, управления рисками и обеспечения были объединены в один договор: Котел . Следуя подходу MakerDAO, мы распределили казначейские функции по Присоединиться контракты, каждый из которых посвящен конкретному активу.

Мы обновили нашу интеграцию с оракулами, объединив оракулов цен и процентных ставок в единую систему. Общий интерфейс . Мы перевернули поток оракула из MakerDAO так, что Cauldron советуется с оракулами по мере необходимости для проверки обеспечения. Насколько мне известно, этот вариант является предпочтительным везде, кроме MakerDAO.

Еще одним существенным отклонением от подхода MakerDAO стало введение нами Ковш . Этот контракт служит единственным посредником между пользователями и Yield. Он обеспечивает обширный контроль над казначейством и бухгалтерским учетом, но взамен предлагает огромную гибкость для разработки функций .

Вкратце, заимствование в Yield v2 работает следующим образом:

• Каждый актив имеет собственный специальный казначейский контракт, обеспечивающий максимальное распределение казначейских функций.
• Единый контракт централизует функцию бухгалтерского учета. Этот контракт также контролирует меры по управлению рисками и осуществляет проверки обеспечения.
• Функция обеспечения обращается к оракулам для определения цен и процентных ставок.
• Оракулы цен и процентных ставок имеют единый интерфейс.
• Процентные ставки генерируются извне.
• Пользователи могут брать кредиты, сделав один запрос только к одному контракту.

Архитектурная эволюция сложных финансов

первая версия соединения был Подтверждение концепции , демонстрируя, что на Ethereum можно создать денежный рынок. По этой причине в его конструкции приоритет отдавался простоте. MoneyMarket.sol контракт инкапсулирует все функции, включая кредитование.

• Задачи казначейства, бухгалтерского учета и управления рисками, такие как проверка обеспечения, объединены в один контракт.
• Этот контракт получает цены от оракулов, но определяет процентные ставки на основе использования активов.
• Пользователи взаимодействуют исключительно с этим контрактом, хотя им приходится делать отдельные вызовы для предоставления залога и заимствования активов.

Соединение v2

Compound v2 был запущен в мае 2019 года. , положив начало эпохе доходного земледелия и вдохновив на создание бесчисленных вилок. Он также функционировал как денежный рынок, позволяя пользователям как кредитовать, так и занимать активы.

На основе его белая бумага и структуру, очевидно, что основная цель Соединение v2 было использовать Стандарт ERC20 для представления кредитных позиций . Это обеспечило компонуемость, позволяя пользователям кредитовать Compound, а затем использовать эти процентные позиции в других приложениях блокчейна.

Интересно, что в официальном документе не указано, что Compound v2 включает в себя награды в свои смарт-контракты. Учитывая это упущение, огромное влияние этой функции можно было не предвидеть.

• Каждый актив имеет свой собственный казначейский контракт, что максимизирует распределение казначейской функции.
• Функция бухгалтерского учета также распределена: каждый cToken учитывает залог и долг пользователя.
• Единый контракт, Контролер, регистрирует и обеспечивает соблюдение параметров управления рисками, включая проверки обеспечения.
• Контракт, отвечающий за проверку обеспечения, ссылается на оракулы для цен и cToken для процентных ставок.
• Оракулы цен и процентных ставок работают с разными интерфейсами.
• Процентная ставка зависит от использования активов.
• Чтобы получить кредит, пользователи должны взаимодействовать с несколькими контрактами.

Соединение v3

Выпущено в 2022 году , Соединение v3 принимает более консервативную стратегию управления рисками, разделяя ликвидность на бассейн за каждый заемный актив. Дизайн также демонстрирует обеспокоенность по поводу удобства использования и затрат на газ.

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

Другие важные функции, упомянутые в примечания к выпуску включать:

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

Интересно, что Compound v3 отражает архитектуру Compound v1, поскольку один контракт обрабатывает все функции для каждого заимствованного актива. Другие примечательные особенности включают в себя:

• Заимствовать можно только заемные активы; залоговые активы не могут.
• Залог не приносит доход в Compound v3.

Запрет на получение залога повышает безопасность тех, кто вносит залог. Это снижает вероятность того, что ошибки управления или преднамеренные атаки поставят под угрозу залог.

Устранение доходов от предоставленного залога может быть результатом того, что Compound удалось накопить много ликвидности в версии 2. У меня есть интуиция, что в Compound v2 лимиты заимствований были либо ниже, либо не намного выше, чем активы, предоставленные приложению пользователями.

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

С архитектурной точки зрения:

• Каждый денежный рынок представляет собой отдельный контракт со своим казначейством, бухгалтерским учетом и управлением рисками.
• Каждый денежный рынок сохраняет заемный актив вместе со всеми утвержденными токенами залоговых активов, в результате чего активы распределяются по приложению.
• Ценовые потоки являются единственным внешним источником данных; процентные ставки по займам и кредитам генерируются внутри компании
• Традиционные функции, такие как поставка/снятие средств/заимствование/погашение, были разумно объединены. Теперь вывод заемного актива с денежного рынка подразумевает заимствование, а его предоставление означает погашение или кредитование на основе долга пользователя.
• Контракт маршрутизации интегрирован, что позволяет выполнять несколько операций за один вызов.

Архитектурная эволюция Aave

Ааве v1 был запущен в октябре 2019 года , пришедший на смену ETHLend. Вместо однорангового подхода ETHLend в Aave v1 был представлен общий пул ликвидности.

Как и в случае с доходностью v2, контракт маршрутизатора также содержит бизнес-логику. КредитованиеПулЯдро реализованы функции бухгалтерского учета, управления рисками и казначейства. Объединение казны в одном контракте было отличительной чертой Compound v2.

Решение оставить чеки обеспечения свой собственный контракт , вызываемый с маршрутизатора, а не контракт на учет, кажется слабым, но, вероятно, он подходил для этой цели, поскольку Aave v2 был выпущен только через два года после выпуска v1.

• Контракт LendingPoolCore занимается казначейством и бухгалтерским учетом.
• LendingPoolDataProvider управляет проверками обеспечения и взаимодействует с оракулом.
• LendingPool служит точкой входа пользователя и реализует бизнес-логику.
• Процентные ставки по займам и кредитам определяются внутри компании, полагаясь исключительно на ценовые потоки.

Ааве v2

Ааве v2 был выпущен в декабре 2021 года . Хотя он сохранил функции, аналогичные Aave v1, он представил улучшенную и более простую архитектуру по сравнению с Aave v1 и Compound v2. В этом выпуске Aave также представила aТокены (аналогично cTokens Compound) и vТокены , которые представляют собой токенизированный долг.

Некоторые функции Aave v1, которые имели ограниченное использование, были опущены для простоты. Проблемы Aave v1, такие как сложное представление начисленных процентов, были решены в Aave v2.

• Контракт LendingPool объединяет глобальные функции бухгалтерского учета и управления рисками, такие как проверки обеспечения. Он служит основной точкой доступа для пользователей.
• aTokens обозначают залог и аналогичны кредитным позициям. Обеспечение пользователей отражается в их активах aToken, а казначейская функция распределяется по всем aTokens.
• vTokens используются для представления долговых позиций. Долг пользователя представлен имеющимися у него токенами vToken.

Ааве v3

Ааве v3 был выпущен в январе 2023 г. с поддержкой нескольких цепочек и другими функциями. Эти дополнения не меняют основную архитектуру. Обновление также может похвастаться улучшенным управлением рисками и эффективностью использования газа.

Несмотря на многочисленные усовершенствования, для целей данного исследования Aave v3 существенно не отличается от Aave v2. Фактически, это может означать, что архитектура Aave v2 останется устойчивой в 2023 году.

Архитектурная эволюция Эйлера

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

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

Несмотря на то, что в одном контракте хранятся все активы, данные учета и управления рисками, по-прежнему существуют eTokens для залога и кредитования, а также dTokens для долга, аналогично Aave v2. Однако эти контракты токенов представляют собой всего лишь представления контракта центрального хранилища.

• Хранилище контракт управляет учетными переменными.
• Базовая логика контракт выполняет функцию казначейства.
• Управляющий рисками контракт контролирует переменные и функции управления рисками, включая проверки обеспечения.

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

Этот унифицированный дизайн также поддерживает простые обновления. Модули можно быстро заменить для внесения изменений или добавления новых функций , если изменения в хранилище не требуются .

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

Я не думаю, что монолитная архитектура сыграла роль в истощении активов; скорее, это был недостаточный надзор за обновлениями кода .

Заключение

Ранние приложения Ethereum, такие как MakerDAO, Compound и Aave, продемонстрировали потенциал заимствований с избыточным обеспечением на Ethereum. Как только эти проверки концепции оказались успешными, акцент сместился на внедрение ряда новых функций для захвата доли рынка. В более поздних версиях Compound и Aave были реализованы методы доходного земледелия, компонуемость и объединенная ликвидность, которые особенно процветали в условиях бычьего рынка.

Существенным достижением стало введение в Compound v2 токенизированных кредитных позиций, что позволило другим приложениям признавать эти позиции в качестве стандартных активов. Aave v2 и Euler пошли еще дальше, внедрив токенизированные долговые позиции, более широкая полезность которых остается предметом споров.

Высокие затраты на газ стали серьезной проблемой во время бычьего рынка, что привело к изменению пользовательского опыта, как это видно в Yield v2, Aave v2 и Euler. Контракты маршрутизаторов и монолитные реализации помогли снизить затраты пользователей на транзакции. Однако это произошло за счет более сложного и, следовательно, более рискованного кода.

Похоже, что Compound v3 создает прецедент, отдавая приоритет безопасности над финансовой эффективностью. Он отличается от традиционной модели пула ликвидности, чтобы лучше защититься от потенциальных взломов. Развитие сетей L2, где стоимость газа становится все более незначительной, вероятно, будет определять структуру будущих заявок на получение залоговых займов.

В этой статье я представил всеобъемлющий обзор ключевых приложений залогового заимствования на Ethereum. Подход, который я использовал для анализа каждой заявки, также может быть применен для быстрого понимания тонкостей других заявок на заимствование под залог.

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

Спасибо за чтение, и удачи.

Благодаря Кальникс за просмотр и редактирование этой статьи.