Anleihen bei Ethereum: Vergleich der Architekturentwicklung von MakerDAO, Yield, Aave, Compound und Euler

Kreditaufnahme ist ein Eckpfeiler von Ethereum-basierten Blockchain-Anwendungen . Mit Milliarden an Vermögenswerten wurden ausgeliehen Daher ist es für Entwickler, Architekten oder Forscher von entscheidender Bedeutung, zu verstehen, wie Kredite funktionieren.

Ähnlich wie die Entwicklung von Programmierparadigmen verfügen diese DeFi-Anwendungen über unterschiedliche Architekturdesigns, die sich ändernde Prioritäten widerspiegeln, die von Sicherheit über Effizienz bis hin zu Benutzererfahrung reichen.

Diese Analyse befasst sich mit der Architektur von Anwendungen wie MakerDAO , Verbindung , Aave , Euler , Und Ertrag . Wir werden wichtige Innovationen und Designmuster hervorheben, die wichtige Erkenntnisse für die Entwicklung zukünftiger Kreditanwendungen sind.

Wenn Sie Entwickler, Architekt oder Sicherheitsforscher sind, ist dieser Artikel genau das Richtige für Sie. Am Ende werden Sie neue Kreditanwendungen auf Ethereum leicht verstehen und deren Architektur schnell und umfassend erfassen. Tauchen Sie ein und erfahren Sie, wie diese DeFi-Giganten von Grund auf aufgebaut sind.

Kreditaufnahme in DeFi

Die meisten DeFi-Kredite sind überbesichert . Ein Benutzer kann einen bestimmten Vermögenswert ausleihen, wenn er Sicherheiten bereitstellt, die höher sind als der Kredit. Im Gegensatz zu herkömmlichen Krediten gibt es bei vielen dieser Kredite keine regelmäßigen Rückzahlungen oder festen Endtermine. Im Wesentlichen können Sie Kredite aufnehmen und niemals zurückzahlen.

Allerdings gibt es einen Haken.

Der Wert der Sicherheit muss den Kreditwert immer um eine vorher festgelegte Marge übersteigen .

Unterschreitet der Beleihungswert diesen, erfolgt der Kredit liquidiert .

Bei der Liquidation zahlt eine andere Person Ihren Kredit ganz oder teilweise zurück und erhält dafür im Gegenzug einen Teil oder die gesamte Sicherheit.

Alle Kreditanträge, die dieser Finanzstruktur folgen, benötigen dieselben Bausteine, die dann auf viele Arten angeordnet werden können:

• Eine Schatzkammer zur Aufbewahrung von Benutzersicherheiten und geliehenen Vermögenswerten
• Ein Buchhaltungssystem, das die Sicherheiten und Schulden jedes Benutzers verfolgt
• Funktionen, die den Zinssatz des Kreditnehmers bestimmen
• Ein Mechanismus zur Überprüfung, ob ein Kredit ausreichend besichert ist, in der Regel unter Einbeziehung externer Preisorakel
• Ein Liquidationspfad für unterbesicherte Kredite
• Risikomanagementsysteme, die die gesamten geliehenen Beträge und andere Sicherheitskennzahlen aufzeichnen, wie z. B. globale und benutzerbezogene Kreditlimits, Mindestbesicherungen und spezifische Überbesicherungsquoten
• Eine Schnittstelle, über die Benutzer Sicherheiten hinzufügen und entfernen, Basiswerte ausleihen und zurückzahlen können
  

Kreditaufnahme und Kreditvergabe können als separate Funktionen betrachtet werden. In DeFi finden wir beide Funktionen in den meisten Kreditanwendungen, sie sind jedoch nicht immer gut integriert .

In Compound, Aave und Euler sind sie . Die Zinssätze für Kreditnehmer und Kreditgeber korrelieren intern; Genau das sorgt dafür, dass diese Anwendungen mit minimalem Eingriff funktionieren.

Andererseits sind MakerDAO und Yield Urheber der Vermögenswerte, die sie an Kreditnehmer verleihen.

Sie verlangen nicht, dass Benutzer Vermögenswerte bereitstellen, damit andere Benutzer Kredite aufnehmen können .

Dieser Artikel konzentriert sich auf die Kreditaufnahme in der Kette und ignoriert die Kreditvergabe weitgehend. Die Kreditaufnahme ist aufgrund der Besicherungspflicht viel komplizierter, und das Verständnis des Kreditaufnahmemusters ermöglicht in der Regel ein besseres Verständnis des gesamten Protokolls.

Die architektonische Entwicklung von MakerDAO

MakerDAO , alt in Ethereum-Begriffen, wurde in seiner jetzigen Form im November 2019 ins Leben gerufen , und es hält Sicherheiten in Höhe von 4,95 Milliarden US-Dollar . Trotz seiner modularen Architektur mit unterschiedlichen Verträgen für jede Funktion und einzigartiger Terminologie bleibt es leicht zu verstehen und zu überprüfen.

Die Treasury-Funktion in MakerDAO wird von verwaltet Verbinden Verträge.

Da ist ein separater Vertrag für jeden als Sicherheit genehmigten Token.

Im Gegensatz dazu verfügt MakerDAO über keinen DAI, den leihenden Vermögenswert.

Stattdessen ist es lediglich prägt und brennt DAI nach Bedarf.

Die Buchhaltung erfolgt innerhalb der MwSt . .sol Vertrag. Die Joins diesen Vertrag aktualisieren wenn Sicherheiten in das System gelangen oder es verlassen. Wenn ein Benutzer einen Kredit ausleiht, wird er direkt mit dem vat.sol-Vertrag interagieren .

Diese Aktion aktualisiert den Schuldensaldo des Benutzers und ermöglicht ihm, DAI beim DAI-Beitritt zu prägen.

Zur Rückzahlung verbrennen Benutzer DAI im DAI-Beitritt. Durch diesen Vorgang wird dann die Mehrwertsteuer aktualisiert, sodass der Benutzer seinen Kredit begleichen kann .

Darüber hinaus dient der vat.sol Vertrag als Risikomanagement Motor. Es verwaltet globale Kreditlimits, legt Mindestschwellenwerte pro Benutzer fest und überwacht die Besicherungsquoten.

Wenn Änderungen am Schulden- oder Sicherheitensaldo eines Benutzers vorgenommen werden, bewertet der vat.sol-Vertrag sowohl den Zinssatz als auch den Kassakurs.

Diese beziehen sich auf den Zinssatz basierend auf den verwendeten Sicherheiten und dem vorherrschenden DAI-zu-Sicherheiten-Preisverhältnis. Interessanterweise werden diese Werte von anderen MakerDAO-Verträgen in den vat.sol-Vertrag eingespeist, eine Methode, die sich von den meisten anderen Anwendungen unterscheidet.

MakerDAO legte in seiner Entwurfsphase großen Wert auf Sicherheit – zu einer Zeit, in der Faktoren wie Gaskosten zweitrangig waren , das Benutzererlebnis nur eine untergeordnete Rolle spielte und der Wettbewerb vernachlässigbar war.

Folglich kann es eigenartig, kostspielig in der Nutzung und schwierig in der Navigation erscheinen.

Dennoch unterstreichen die enormen Vermögenswerte, die es verwaltet, und die Tatsache, dass es ohne nennenswerte Verstöße funktioniert, sein robustes Design und seine robuste Ausführung.

Höhepunkte:

• Jeder Vermögenswert hat seinen eigenen Vertrag in der Treasury-Funktion mit maximaler Streuung
• Die Buchhaltungsfunktion ist in einem einzigen Vertrag zentralisiert, der auch Risikoparameter, einschließlich Besicherungsprüfungen, dokumentiert und durchsetzt
• Im Gegensatz zu anderen Apps aktualisieren Oracles den Vertrag und überwachen die Besicherung
• Preis- und Zinsorakel nutzen unterschiedliche Schnittstellen
• Der Zinssatz entsteht extern
• Um Kredite aufzunehmen, müssen Benutzer mit mehreren Verträgen interagieren

Die architektonische Entwicklung des Ertragsprotokolls

Ertrag v1 diente als Proof of Concept für die Nutzung fester Tarife YieldSpace . Diese Version baute ihre besicherte Schulden-Engine auf MakerDAO auf. Allerdings war die Nutzung von Yield v1 sowohl kostspielig als auch schwierig mit neuen Funktionen zu erweitern.

Da wir das Potenzial von YieldSpace erkannten, begannen wir schnell mit der Entwicklung Ertrag v2 . Immer noch von MakerDAO inspiriert, aber jetzt völlig unabhängig, Yield v2 im Oktober 2021 gestartet ; Bei Yield v2 standen reduzierte Gaskosten und ein verbessertes Benutzererlebnis im Vordergrund.

Alle Buchhaltungs-, Risikomanagement- und Besicherungsprüfungen wurden in einem Vertrag zusammengefasst: dem Kessel . In Anlehnung an den Ansatz von MakerDAO haben wir die Treasury-Funktionen verteilt Verbinden Verträge, die jeweils einem bestimmten Vermögenswert gewidmet sind.

Wir haben unsere Oracle-Integration überarbeitet und Preis- und Zinsorakel zu einem zusammengeführt gemeinsame Schnittstelle . Wir haben den Orakelfluss von MakerDAO so umgekehrt, dass Cauldron befragt Orakel soweit zur Besicherungsprüfung erforderlich. Meines Wissens ist dies überall außer MakerDAO der bevorzugte Ablauf.

Eine weitere wesentliche Abweichung vom Ansatz von MakerDAO war unsere Einführung des Kelle . Dieser Vertrag dient als alleiniger Vermittler zwischen Nutzern und Yield. Es verfügt über umfassende Kontrolle über Treasury und Buchhaltung, bietet aber im Gegenzug enorme Flexibilität für die Funktionsentwicklung .

Zusammenfassend funktioniert die Kreditaufnahme in Yield v2 wie folgt:

• Jeder Vermögenswert verfügt über einen eigenen Treasury-Vertrag, der eine maximale Verteilung der Treasury-Funktion gewährleistet.
• Ein einzelner Vertrag zentralisiert die Buchhaltungsfunktion. Dieser Vertrag überwacht auch Risikomanagementmaßnahmen und führt Besicherungsprüfungen durch.
• Die Besicherungsfunktion konsultiert Orakel, um Preise und Zinssätze zu ermitteln.
• Sowohl Preis- als auch Zinsorakel nutzen eine einheitliche Schnittstelle.
• Zinssätze werden extern generiert.
• Benutzer können Kredite aufnehmen, indem sie eine einzige Anfrage für nur einen Vertrag stellen.

Die architektonische Entwicklung der Compound Finance

Der erste Version von Compound war ein Konzeptioneller Beweiß Dies zeigt, dass auf Ethereum ein Geldmarkt eingerichtet werden könnte. Aus diesem Grund wurde beim Design Wert auf Einfachheit gelegt. Der MoneyMarket.sol Der Vertrag umfasst alle Funktionen, einschließlich der Kreditvergabe.

• Die Treasury-, Buchhaltungs- und Risikomanagementaufgaben, wie z. B. Besicherungsprüfungen, werden in einem Vertrag zusammengefasst.
• Dieser Vertrag ruft die Preise von den Orakeln ab, bestimmt aber die Zinssätze auf der Grundlage der Vermögensauslastung.
• Benutzer interagieren ausschließlich mit diesem Vertrag, müssen jedoch separate Anrufe tätigen, um Sicherheiten bereitzustellen und Vermögenswerte auszuleihen.

Verbindung v2

Compound v2 wurde im Mai 2019 eingeführt , läutete die Ära der Ertragslandwirtschaft ein und inspirierte unzählige Forks. Auch er fungierte als Geldmarkt, der es den Nutzern ermöglichte, Vermögenswerte sowohl zu verleihen als auch zu leihen.

Basierend auf seiner weißes Papier und Struktur, es ist offensichtlich, dass ein großes Ziel für Verbindung v2 war die zu verwenden ERC20-Standard zur Darstellung von Kreditpositionen . Dies stellte die Zusammensetzbarkeit sicher und ermöglichte es Benutzern, Kredite an Compound zu vergeben und diese verzinslichen Positionen dann in anderen Blockchain-Anwendungen zu verwenden.

Interessanterweise wurde im Whitepaper nicht hervorgehoben, dass Compound v2 integriert ist Belohnung in seine Smart Contracts integrieren. Aufgrund dieser Unterlassung waren die immensen Auswirkungen dieser Funktion möglicherweise nicht vorhersehbar.

• Jeder Vermögenswert verfügt über einen eigenen Treasury-Vertrag, wodurch die Verteilung der Treasury-Funktion maximiert wird.
• Die Buchhaltungsfunktion ist ebenfalls verteilt, wobei jeder cToken die Sicherheiten und Schulden des Benutzers vermerkt.
• Ein einzelner Vertrag, der Comptroller, protokolliert und erzwingt Risikomanagementparameter, einschließlich Besicherungsprüfungen.
• Der für die Besicherungsprüfung zuständige Vertrag referenziert die Orakel für Preise und den cToken für Zinssätze.
• Die Preis- und Zinsorakel arbeiten mit unterschiedlichen Schnittstellen.
• Der Zinssatz ergibt sich intern aus der Vermögensauslastung.
• Benutzer müssen mit mehreren Verträgen interagieren, um Kredite aufzunehmen.

Verbindung v3

Veröffentlicht im Jahr 2022 , Verbindung v3 verfolgt eine konservativere Risikomanagementstrategie und verteilt die Liquidität auf a Schwimmbad für jeden leihbaren Vermögenswert. Das Design lässt auch Bedenken hinsichtlich der Benutzerfreundlichkeit und der Gaskosten erkennen.

Aufgrund der geringeren Anzahl erforderlicher Anrufe ist das System sowohl für Entwickler als auch für Benutzer intuitiver. Darüber hinaus reduziert das einzigartige Vertragsdesign die Gaskosten durch die Minimierung der Anrufe zwischen Verträgen. Die getrennten Geldmärkte dienen als Schutz vor Angriffen auf Orakelbasis, die mittlerweile ein großes Sicherheitsrisiko darstellen.

Weitere relevante Merkmale, die in der erwähnt werden Versionshinweise enthalten:

• Eine komplett überarbeitete Risikomanagement- und Liquidations-Engine. Dieses Design erhöht die Fondssicherheit und ist gleichzeitig kreditnehmerfreundlicher.
• Legen Sie marktweit Grenzwerte für einzelne Sicherheiten fest, um Risiken zu mindern.
• Die Zinsmodelle für Einkommen und Kreditaufnahme sind nun getrennt, wobei die Governance die vollständige Kontrolle über die Wirtschaftspolitik hat.

Interessanterweise spiegelt Compound v3 die Architektur von Compound v1 wider, indem ein einziger Vertrag alle Funktionen für jeden leihbaren Vermögenswert abwickelt. Weitere bemerkenswerte Merkmale sind:

• Es können nur geliehene Vermögenswerte geliehen werden; Sicherheiten können dies nicht.
• Sicherheiten bringen in Compound v3 keine Rendite.

Das Verbot der Kreditaufnahme von Sicherheiten erhöht die Sicherheit für die Hinterlegung der Sicherheiten. Dies verringert die Wahrscheinlichkeit, dass Governance-Fehler oder vorsätzliche Angriffe die Sicherheiten gefährden.

Der Wegfall der Erträge aus bereitgestellten Sicherheiten könnte darauf zurückzuführen sein, dass es Compound in Version 2 gelungen ist, viel Liquidität anzuhäufen. Ich habe den Eindruck, dass in Compound v2 die Kreditlimits entweder niedriger oder nicht viel höher waren als die Vermögenswerte, die die Benutzer der Anwendung verliehen haben.

Unter der Annahme, dass sie für Version 3 ein ähnliches Liquiditätsniveau verwalten, macht das Verbot der Ausleihe von Sicherheiten die Anwendung sicher, was eines der Kernziele von Version 3 ist.

Aus architektonischer Sicht:

• Jeder Geldmarkt ist ein individueller Vertrag mit seinem Treasury, seiner Buchhaltung und seinem Risikomanagement
• Jeder Geldmarkt behält den leihbaren Vermögenswert zusammen mit allen genehmigten Sicherheiten-Asset-Tokens, wodurch die Vermögenswerte über die Anwendung verteilt werden
• Preis-Feeds sind der einzige externe Input; Zinssätze für Kredite und Kredite werden intern generiert
• Traditionelle Funktionen wie Bereitstellen/Abheben/Ausleihen/Rückzahlen wurden intelligent konsolidiert. Nun bedeutet die Entnahme eines leihbaren Vermögenswerts von einem Geldmarkt eine Kreditaufnahme, während die Bereitstellung eine Rückzahlung oder Kreditvergabe auf der Grundlage der Schulden des Nutzers bedeutet
• Ein Routing-Vertrag ist integriert und ermöglicht mehrere Vorgänge in einem einzigen Anruf

Die architektonische Entwicklung von Aave

Aave v1 War im Oktober 2019 gestartet , Nachfolger von ETHLend. Anstelle des Peer-to-Peer-Ansatzes von ETHLend führte Aave v1 einen gemeinsamen Liquiditätspool ein.

Wie in Yield v2 ist die Router-Vertrag hielt auch die Geschäftslogik. Der LendingPoolCore implementierte Buchhaltungs-, Risikomanagement- und Treasury-Funktionen. Die Bündelung des Treasury in einem einzigen Vertrag war ein Unterscheidungsmerkmal zu Compound v2.

Die Entscheidung, die Besicherung zu belassen, erfolgt einen eigenen Vertrag , vom Router aufgerufen und nicht der Abrechnungsvertrag, scheint schwach zu sein, war aber wahrscheinlich zweckdienlich, da Aave v2 erst zwei Jahre nach der Veröffentlichung von v1 veröffentlicht wurde

• Der LendingPoolCore-Vertrag kümmert sich um Treasury und Buchhaltung
• LendingPoolDataProvider verwaltet Besicherungsprüfungen und interagiert mit dem Orakel
• LendingPool dient als Benutzereinstiegspunkt und implementiert die Geschäftslogik
• Die Zinssätze für Kredite und Kredite werden intern festgelegt und basieren ausschließlich auf Preisdaten

Aave v2

Aave v2 War veröffentlicht im Dezember 2021 . Es behielt zwar ähnliche Funktionen wie Aave v1 bei, führte jedoch im Vergleich zu Aave v1 und Compound v2 eine verbesserte und einfachere Architektur ein. Mit dieser Version stellte Aave auch vor aTokens (ähnlich den cTokens von Compound) und vTokens , die tokenisierte Schulden darstellen.

Bestimmte Funktionen von Aave v1, die nur begrenzten Nutzen hatten, wurden der Einfachheit halber weggelassen. Probleme in Aave v1, wie die komplexe Darstellung aufgelaufener Zinsen, wurden in Aave v2 behoben.

• Der LendingPool-Vertrag bündelt globale Buchhaltungs- und Risikomanagementfunktionen, wie beispielsweise Besicherungsprüfungen. Es dient als primärer Zugangspunkt für Benutzer
• aTokens stellen Sicherheiten dar und ähneln Kreditpositionen. Die Sicherheiten der Nutzer spiegeln sich in ihren aToken-Beständen wider und die Treasury-Funktion ist auf alle aTokens verteilt
• vTokens werden zur Darstellung von Schuldenpositionen verwendet. Die Schulden eines Benutzers werden durch die von ihm gehaltenen vTokens repräsentiert

Aave v3

Aave v3 War veröffentlicht im Januar 2023 mit Multi-Chain-Unterstützung und anderen Funktionen. Diese Ergänzungen verändern die Kernarchitektur nicht. Das Update zeichnet sich außerdem durch ein verbessertes Risikomanagement und eine verbesserte Gaseffizienz aus.

Trotz seiner vielen Fortschritte unterscheidet sich Aave v3 für die Zwecke dieser Studie nicht wesentlich von Aave v2. Tatsächlich könnte es darauf hindeuten, dass die Architektur von Aave v2 auch im Jahr 2023 robust bleibt.

Die architektonische Entwicklung von Euler

Euler War im Dezember 2022 gestartet mit dem Ziel, Geldmärkte mit erlaubnisfreien Funktionen und minimaler Governance anzubieten.

Ein Markenzeichen seines Designs ist das diamantartig Muster. A Ein einziger Vertrag enthält den gesamten Speicher der Anwendung . Auf diesen Speicher kann über „distinct“ zugegriffen werden Proxys , wobei jeder ein anderes konzeptionelles Element des Systems verwaltet.

Obwohl in einem Vertrag alle Vermögens-, Buchhaltungs- und Risikomanagementdaten gespeichert sind, gibt es immer noch eTokens für Sicherheiten und Kredite sowie dTokens für Schulden, ähnlich wie bei Aave v2. Bei diesen Token-Verträgen handelt es sich jedoch lediglich um Ansichten des zentralen Speichervertrags.

• Der Lagerung Der Vertrag verwaltet Buchhaltungsvariablen.
• Der BaseLogic Der Vertrag fungiert als Schatzkammer.
• Der Risikomanager Der Vertrag überwacht Variablen und Funktionen des Risikomanagements, einschließlich Besicherungsprüfungen.

Eine Analyse des Codes zeigt, dass minimale Gaskosten Priorität hatten, was dazu führte, dass durch das monolithische Design keine Anrufe zwischen Verträgen erforderlich waren. Die Sicherheit wurde durch strenge Tests und Audits gewährleistet. Lediglich die Logik wurde auf verschiedene Module verteilt und diente als Umsetzung für den Speichervertrag, der in erster Linie als Proxy-Vertrag fungierte.

Dieses einheitliche Design unterstützt auch einfache Upgrades. Module können schnell ausgetauscht werden, um Funktionen zu ändern oder einzuführen , wenn keine Speicheränderungen erforderlich sind .

Euler wurde fünfzehn Monate nach seiner Veröffentlichung und sechs Monate nach Einführung der ausgenutzten Schwachstelle durch das Upgrade gehackt.

Ich glaube nicht, dass die monolithische Architektur zum Abfluss der Vermögenswerte beigetragen hat; Es handelte sich vielmehr um eine unzureichende Überwachung der Codeaktualisierungen .

Abschluss

Frühe Ethereum-Anwendungen wie MakerDAO, Compound und Aave zeigten das Potenzial einer überbesicherten Kreditaufnahme auf Ethereum. Nachdem sich diese Konzeptnachweise als erfolgreich erwiesen hatten, verlagerte sich der Schwerpunkt auf die Einführung einer Mischung neuer Funktionen, um Marktanteile zu gewinnen. Die späteren Versionen von Compound und Aave führten Yield Farming, Zusammensetzbarkeit und gepoolte Liquidität ein, was besonders in bullischen Marktbedingungen florierte.

Eine bedeutende Entwicklung war die Einführung tokenisierter Kreditpositionen in Compound v2, die es ermöglichten, diese Positionen von anderen Anwendungen als Standardvermögenswerte zu erkennen. Aave v2 und Euler gingen noch einen Schritt weiter und implementierten tokenisierte Schuldenpositionen, deren breiterer Nutzen weiterhin Gegenstand von Debatten ist.

Hohe Gaskosten erwiesen sich während des Bullenmarktes als großes Problem und führten zu Änderungen der Benutzererfahrung, wie bei Yield v2, Aave v2 und Euler zu beobachten war. Router-Verträge und monolithische Implementierungen trugen dazu bei, die Transaktionskosten für Benutzer zu senken. Dies ging jedoch zu Lasten eines komplexeren und damit riskanteren Codes.

Compound v3 scheint einen Präzedenzfall zu schaffen, da Sicherheit Vorrang vor finanzieller Effizienz hat. Es weicht vom traditionellen Liquiditätspoolmodell ab, um sich besser vor potenziellen Hacks zu schützen. Der Aufstieg von L2-Netzen, bei denen die Gaskosten zunehmend vernachlässigbar werden, wird wahrscheinlich die Gestaltung zukünftiger besicherter Kreditanträge beeinflussen.

In diesem Artikel habe ich einen umfassenden Überblick über die wichtigsten besicherten Kreditanträge auf Ethereum gegeben. Der Ansatz, den ich zur Analyse jedes Antrags verwendet habe, kann auch angewendet werden, um die Feinheiten anderer besicherter Kreditanträge schnell zu erfassen.

Berücksichtigen Sie bei der Entwicklung einer Blockchain-Kreditanwendung immer die Speicherung von Vermögenswerten, die Platzierung von Buchhaltungsunterlagen und die Methoden zur Risiko- und Sicherheitenbewertung. Wenn Sie diese Überlegungen durcharbeiten, stützen Sie sich bei Ihren Entscheidungen auf den Verlauf früherer Bewerbungen und die Erkenntnisse aus dieser Übersicht.

Vielen Dank fürs Lesen und viel Glück.

Dank an Calnix für die Durchsicht und Bearbeitung dieses Artikels.