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

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

Цей аналіз розглядає архітектуру таких програм, як MakerDAO, Compound, Aave, Euler і Yield. Ми висвітлимо ключові інновації та шаблони дизайну, які є важливими уроками для розробки майбутніх програм кредитування.

Якщо ви розробник, архітектор або дослідник безпеки, ця стаття для вас. Зрештою, ви легко зрозумієте нові програми запозичення на Ethereum, швидко й всебічно зрозумієте їхню архітектуру. Пориньте, щоб побачити, як ці гіганти DeFi побудовані з нуля.

Запозичення в DeFi

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

Однак тут є заковика.

Вартість застави завжди повинна перевищувати вартість кредиту на заздалегідь визначену маржу.

Якщо вартість застави падає нижче цього, кредит ліквідується.

Під час ліквідації хтось інший повертає частину або всю вашу позику, а натомість отримує частину або всю вашу заставу.

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

• Казначейство для зберігання застави користувачів і позичених активів
• Система обліку, яка відстежує заставу та заборгованість кожного користувача
• Функції, що визначають процентну ставку позичальників
• Механізм перевірки того, чи позика забезпечена достатньою заставою, зазвичай із залученням зовнішніх цінових оракулів
• Шлях ліквідації для кредитів із недостатнім забезпеченням
• Системи управління ризиками, які реєструють загальну суму запозичених коштів та інші показники безпеки, як-от глобальні ліміти запозичень і ліміти позик на кожного користувача, мінімальний розмір застави та конкретні коефіцієнти надмірної застави
• Інтерфейс для користувачів, щоб додавати та видаляти заставу, позичати та погашати базові кошти

Процес запозичення в MakerDAO. Усі програми мають однакові дії та функції.

Позику та позику можна розглядати як окремі ознаки. У DeFi ми знаходимо обидві функції в більшості програм для запозичень, але вони не завжди добре інтегровані.

У Compound, Aave та Euler вони є. Процентні ставки для позичальників і кредиторів внутрішньо корельовані; власне, саме це змушує ці програми працювати з мінімальним втручанням.

З іншого боку, MakerDAO та Yield є авторами активів, які вони позичають позичальникам.

Вони не вимагають від користувачів надавати активи, щоб інші користувачі могли позичити.

Ця стаття буде зосереджена на запозиченнях у мережах і здебільшого ігноруватиме кредитування. Запозичення набагато складніше через вимогу забезпечення, і розуміння моделі запозичення зазвичай відкриває краще розуміння всього протоколу.

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

Логотип MakerDAO

MakerDAO, стародавній з точки зору Ethereum, був запущений у своїй поточній формі в листопаді 2019 року, і він має 4,95 мільярда доларів у якості застави. Незважаючи на модульну архітектуру з окремими контрактами для кожної функції та унікальну термінологію, її легко зрозуміти та перевірити.

Функцією казначейства в MakerDAO керують контракти Join .

Для кожного токена, затвердженого як заставний актив, існує окремий контракт .

Навпаки, MakerDAO не має DAI, позикового активу.

Замість цього він просто карбує та записує DAI за потреби.

Бухгалтерський облік ведеться в рамках договору ПДВ. Приєднання оновлюють цей договір , коли забезпечення надходить або виходить із системи. Якщо користувач позичає, він безпосередньо взаємодіє з контрактом vat.sol.

Ця дія оновлює баланс боргу користувача та дозволяє йому карбувати DAI у DAI Join.

Щоб відшкодувати, користувачі записують DAI у DAI Join. Цей процес потім оновлює ПДВ, що дозволяє користувачеві погасити свою позику.

Крім того, контракт vat.sol служить механізмом управління ризиками . Він підтримує глобальні ліміти запозичень, встановлює мінімальні пороги для кожного користувача та контролює коефіцієнти забезпечення.

Коли вносяться зміни до заборгованості або балансу застави користувача, контракт vat.sol оцінює як ставку, так і спот.

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

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

Відповідно, він може здатися дивним, дорогим у використанні та складним для навігації.

Проте величезні активи, якими вона управляє, і результати роботи без значних порушень підкреслюють її надійну конструкцію та виконання.

Основні моменти:

• Кожен актив має власний контракт у функції казначейства з максимальним розповсюдженням
• Функція бухгалтерського обліку централізована в рамках єдиного договору, який також документує та забезпечує дотримання параметрів ризику, включаючи перевірки застави
• На відміну від інших додатків, Oracles оновлює договір, контролюючи забезпечення
• Оракули цін і процентних ставок використовують різні інтерфейси
• Процентна ставка виникає ззовні
• Щоб позичити, користувачі повинні взаємодіяти з кількома контрактами

Архітектурна еволюція протоколу Yield

Yield v1 служив доказом концепції для фіксованих ставок за допомогою YieldSpace. Ця версія створила свій борговий механізм із заставою на основі MakerDAO. Однак Yield v1 був і дорогим у використанні, і складним для доповнення новими функціями.

Розуміючи потенціал YieldSpace, ми швидко перейшли до розробки Yield v2. Досі черпаючи натхнення з MakerDAO, але тепер повністю незалежний, Yield v2 був запущений у жовтні 2021 року; Yield v2 надає перевагу зменшенню витрат на газ і покращенню взаємодії з користувачем.

Процес запозичення в Yield v2, під сильним впливом MakerDAO

Усі перевірки бухгалтерського обліку, управління ризиками та застави були об’єднані в один контракт: Cauldron. Віддзеркалюючи підхід MakerDAO, ми розподілили функції казначейства між контрактами Join , кожен з яких присвячений певному активу.

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

Іншим значним відхиленням від підходу MakerDAO стало наше впровадження Ladle. Цей договір є єдиним посередником між користувачами та Yield. Він широко контролює казначейство та бухгалтерію, але натомість пропонує величезну гнучкість для розробки функцій.

Підсумовуючи, запозичення в Yield v2 працює наступним чином:

• Кожен актив має власний спеціальний казначейський контракт, що забезпечує максимальний розподіл казначейської функції.
• Єдиний договір централізує функцію бухгалтерського обліку. Цей контракт також передбачає контроль за заходами з управління ризиками та перевірку застави.
• Функція застави консультується з оракулами для визначення цін і процентних ставок.
• Оракули цін і процентних ставок мають єдиний інтерфейс.
• Процентні ставки формуються зовні.
• Користувачі можуть позичити, зробивши один запит лише на один контракт.

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

Перша версія Compound була Proof-of-Concept, яка демонструвала, що грошовий ринок можна створити на Ethereum. З цієї причини в його дизайні пріоритетом була простота. Контракт MoneyMarket.sol охоплює всі функції, включаючи кредитування.

Процес запозичення в Compound v1. Простий, але ефективний.

• Завдання казначейства, бухгалтерського обліку та управління ризиками, наприклад перевірки застави, об’єднані в один контракт.
• Цей контракт отримує ціни з оракулів, але визначає процентні ставки на основі використання активів.
• Користувачі взаємодіють виключно з цим контрактом, хоча вони повинні робити окремі виклики, щоб надати заставу та позичити активи.

З'єднання v2

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

Виходячи з офіційного документа та структури, очевидно, що головною метою Compound v2 було використання стандарту ERC20 для представлення кредитних позицій. Це забезпечило комбінування, дозволяючи користувачам позичати Compound, а потім використовувати ці процентні позиції в інших блокчейн-додатках.

Цікаво, що в технічному документі не наголошується, що Compound v2 включив винагороди в свої смарт-контракти. Враховуючи це упущення, величезний вплив цієї функції можна було не передбачити.

Процес запозичення в Compound v2. Перший набіг на токенізовані кредитні позиції.

• Кожен актив має власний казначейський контракт, що максимізує розподіл казначейської функції.
• Функція обліку також розподілена, при цьому кожен cToken відзначає заставу та борг користувача.
• Окремий контракт, контролер, реєструє та забезпечує дотримання параметрів управління ризиками, включаючи перевірки застави.
• Контракт, який відповідає за перевірку застави, посилається на оракули щодо цін і cToken для процентних ставок.
• Оракули ціни та процентної ставки працюють з різними інтерфейсами.
• Відсоткова ставка випливає з внутрішнього використання активів.
• Щоб позичити, користувачі повинні взаємодіяти з кількома контрактами.

З'єднання v3

Compound v3 , випущений у 2022 році , використовує більш консервативну стратегію управління ризиками, розділяючи ліквідність у пул для кожного позикового активу. Дизайн також виявляє занепокоєння щодо зручності використання та вартості газу.

Процес запозичення в Compound v3 (Comet). Назад до основ, назад до безпеки. Але з кращим UX.

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

Інші відповідні функції, згадані в примітках до випуску , включають:

• Повністю оновлений механізм управління ризиками та ліквідації. Такий дизайн підвищує безпеку коштів, водночас зручніший для позичальника.
• Встановіть обмеження на ринку для окремих заставних активів, щоб зменшити ризики.
• Моделі відсоткової ставки для заробітку та запозичення тепер розділені, а уряд має повний контроль над економічною політикою.

Цікаво, що Compound v3 відображає архітектуру Compound v1, оскільки єдиний контракт обробляє всі функції для кожного позикового активу. Серед інших важливих особливостей:

• Позичити можна лише позичені активи; заставні активи не можуть.
• Застава не дає прибутку в Compound v3.

Заборона на запозичення застави підвищує безпеку для тих, хто вносить заставу. Це зменшує ймовірність того, що помилки управління або навмисні атаки ставлять під загрозу заставу.

Усунення повернення наданої застави може бути результатом того, що Compound вдалося накопичити велику кількість ліквідності у v2. У мене є інтуїція, що в Compound v2 ліміти запозичень були або нижчими, або не набагато вищими за активи, надані додатку користувачами.

Якщо припустити, що вони керуватимуть аналогічними рівнями ліквідності для версії 3, заборона надання застави робить програму безпечною, що є однією з основних цілей версії 3.

З архітектурної точки зору:

• Кожен грошовий ринок — це окремий контракт із своїм казначейством, бухгалтерією та управлінням ризиками
• Кожен грошовий ринок зберігає позиковий актив разом із усіма його схваленими токенами активів застави, внаслідок чого активи розподіляються по програмі
• Подачі цін є єдиним зовнішнім вхідним сигналом; відсоткові ставки для запозичень і позик формуються внутрішньо
• Традиційні функції, такі як постачання/вилучення/позичання/погашення, були розумно консолідовані. Тепер вилучення позиченого активу з грошового ринку означає позику, тоді як надання вказує на погашення або надання в борг на основі боргу користувача
• Контракт маршрутизації інтегрований, що дозволяє виконувати кілька операцій під час одного виклику

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

Aave v1 був запущений у жовтні 2019 року, замінивши ETHLend. Замість однорангового підходу ETHLend Aave v1 представив загальний пул ліквідності.

Процес запозичення в Aave v1. Об’єднана ліквідність означала фінансову та обчислювальну ефективність.

Як і в Yield v2, договір маршрутизатора також містив бізнес-логіку. LendingPoolCore реалізував функції бухгалтерського обліку, управління ризиками та казначейства. Об’єднання скарбниці в одному контракті було відмінним моментом від Compound v2.

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

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

Aave v2

Aave v2 було випущено в грудні 2021 року. Хоча він зберіг функції, подібні до Aave v1, він представив покращену та простішу архітектуру порівняно з Aave v1 та Compound v2. У цьому випуску Aave також представила aTokens (схожі на cTokens від Compound) і vTokens, які представляють токенізований борг.

Aave v2 має дуже чисту архітектуру, повністю токенізовану.

Деякі функції з Aave v1, які мали обмежене використання, були опущені для простоти. Проблеми в Aave v1, як-от складне представлення нарахованих відсотків, були вирішені в Aave v2.

• Контракт LendingPool об’єднує глобальні функції бухгалтерського обліку та управління ризиками, такі як перевірка застави. Він служить основною точкою доступу для користувачів
• aTokens означають заставу та схожі на кредитні позиції. Заставне майно користувачів відображається в їхніх активах aToken, а функція казначейства розподілена між усіма aTokens
• vTokens використовуються для представлення боргових позицій. Борг користувача представлений vTokens, якими він володіє

Aave v3

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

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

Архітектурна еволюція Ейлера

Euler було запущено в грудні 2022 року з метою запропонувати грошові ринки з функціями без дозволу та мінімальним управлінням.

Відмінною рисою його дизайну є ромбовидний малюнок. Єдиний контракт зберігає всю пам’ять програми. Доступ до цього сховища можна отримати через різні проксі-сервери, кожен з яких керує окремим концептуальним елементом системи.

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

• Контракт на зберігання керує обліковими змінними.
• Контракт BaseLogic функціонує як скарбниця.
• Контракт RiskManager наглядає за змінними та функціями управління ризиками, включаючи перевірки забезпечення.

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

Цей уніфікований дизайн також підтримує легке оновлення. Модулі можна швидко замінити, щоб змінити або додати функції, якщо не потрібно змінювати пам’ять.

Euler було зламано через п’ятнадцять місяців після випуску та через шість місяців після того, як оновлення запровадило використану вразливість.

Я не думаю, що монолітна архітектура зіграла роль у виснаженні активів; швидше, це був недостатній нагляд за оновленнями коду.

Висновок

Важка робота завершена, давайте повторимо, що ми навчилися

Ранні додатки Ethereum, такі як MakerDAO, Compound і Aave, продемонстрували потенціал надлишкових запозичень на Ethereum. Після того, як ці докази концепції виявилися успішними, фокус перемістився на впровадження поєднання нових функцій для захоплення частки ринку. Більш пізні версії Compound і Aave представили yield farming, composability та об’єднану ліквідність, які процвітали особливо в умовах зростання ринку.

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

Високі витрати на газ викликали серйозне занепокоєння під час зростання ринку, що спонукало до модифікації взаємодії з користувачем, як це видно в Yield v2, Aave v2 та Euler. Контракти маршрутизаторів і монолітні реалізації допомогли зменшити витрати користувачів на транзакції. Однак це відбулося за рахунок складнішого і, отже, більш ризикованого коду.

Схоже, що Compound v3 створює прецедент, надаючи перевагу безпеці над фінансовою ефективністю. Це відхилення від традиційної моделі пулу ліквідності для кращого захисту від потенційних хакерів. Зростання мереж L2, де витрати на газ стають дедалі незначними, ймовірно, сформує дизайн майбутніх заявок на позики під заставу.

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

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

Дякуємо за читання та бажаємо успіхів.

Дякуємо Calnix за перегляд і редагування цієї статті.

Відмова від відповідальності:

1. Цю статтю передруковано з [hackernoon]. Усі авторські права належать оригінальному автору [alcueca]. Якщо є заперечення щодо цього передруку, будь ласка, зв’яжіться з командою Gate Learn , і вони негайно розглянуть це.
2. Відмова від відповідальності: погляди та думки, висловлені в цій статті, належать виключно автору та не є жодною інвестиційною порадою.
3. Переклади статті на інші мови виконує команда Gate Learn. Якщо не зазначено вище, копіювання, розповсюдження або плагіат перекладених статей заборонено.