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

. Mit Daher ist es für Entwickler, Architekten oder Forscher von entscheidender Bedeutung, zu verstehen, wie Kredite funktionieren. Kreditaufnahme ist ein Eckpfeiler von Ethereum-basierten Blockchain-Anwendungen Milliarden an Vermögenswerten wurden ausgeliehen Ä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 , , , , Und . Wir werden wichtige Innovationen und Designmuster hervorheben, die wichtige Erkenntnisse für die Entwicklung zukünftiger Kreditanwendungen sind. MakerDAO Verbindung Aave Euler Ertrag 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 . 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. überbesichert 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 . Die Zinssätze für Kreditnehmer und Kreditgeber korrelieren intern; Genau das sorgt dafür, dass diese Anwendungen mit minimalem Eingriff funktionieren. In Compound, Aave und Euler sind sie Urheber der Vermögenswerte, die sie an Kreditnehmer verleihen. Andererseits sind MakerDAO und Yield . 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 , alt in Ethereum-Begriffen, und es hält . Trotz seiner modularen Architektur mit unterschiedlichen Verträgen für jede Funktion und einzigartiger Terminologie bleibt es leicht zu verstehen und zu überprüfen. MakerDAO , wurde in seiner jetzigen Form im November 2019 ins Leben gerufen Sicherheiten in Höhe von 4,95 Milliarden US-Dollar Die Treasury-Funktion in MakerDAO wird von verwaltet Verbinden Verträge. Da ist ein für jeden als Sicherheit genehmigten Token. separater Vertrag Im Gegensatz dazu verfügt MakerDAO über keinen DAI, den leihenden Vermögenswert. Stattdessen ist es lediglich nach Bedarf. prägt und brennt DAI Die Buchhaltung erfolgt innerhalb der Vertrag. Die Joins wenn Sicherheiten in das System gelangen oder es verlassen. Wenn ein Benutzer einen Kredit ausleiht, wird er . . .sol MwSt diesen Vertrag aktualisieren 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 Vertrag als Motor. Es verwaltet globale Kreditlimits, legt Mindestschwellenwerte pro Benutzer fest und überwacht die Besicherungsquoten. vat.sol Risikomanagement 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 – , das Benutzererlebnis nur eine untergeordnete Rolle spielte und der Wettbewerb vernachlässigbar war. zu einer Zeit, in der Faktoren wie Gaskosten zweitrangig waren 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 diente als Proof of Concept für die Nutzung fester Tarife . 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. Ertrag v1 YieldSpace Da wir das Potenzial von YieldSpace erkannten, begannen wir schnell mit der Entwicklung . Immer noch von MakerDAO inspiriert, aber jetzt völlig unabhängig, Yield v2 ; Bei Yield v2 standen reduzierte Gaskosten und ein verbessertes Benutzererlebnis im Vordergrund. Ertrag v2 im Oktober 2021 gestartet Alle Buchhaltungs-, Risikomanagement- und Besicherungsprüfungen wurden in einem Vertrag zusammengefasst: dem . In Anlehnung an den Ansatz von MakerDAO haben wir die Treasury-Funktionen verteilt Verträge, die jeweils einem bestimmten Vermögenswert gewidmet sind. Kessel Verbinden Wir haben unsere Oracle-Integration überarbeitet und Preis- und Zinsorakel zu einem zusammengeführt . Wir haben den Orakelfluss von MakerDAO so umgekehrt, dass Cauldron soweit zur Besicherungsprüfung erforderlich. Meines Wissens ist dies überall außer MakerDAO der bevorzugte Ablauf. gemeinsame Schnittstelle befragt Orakel Eine weitere wesentliche Abweichung vom Ansatz von MakerDAO war unsere Einführung des . Dieser Vertrag dient als alleiniger Vermittler zwischen Nutzern und Yield. Es verfügt über umfassende Kontrolle über Treasury und Buchhaltung, . Kelle 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 war ein Dies zeigt, dass auf Ethereum ein Geldmarkt eingerichtet werden könnte. Aus diesem Grund wurde beim Design Wert auf Einfachheit gelegt. Der Der Vertrag umfasst alle Funktionen, einschließlich der Kreditvergabe. erste Version von Compound Konzeptioneller Beweiß MoneyMarket.sol 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 , 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. Compound v2 wurde im Mai 2019 eingeführt Basierend auf seiner und Struktur, es ist offensichtlich, dass ein großes Ziel für war die zu verwenden . 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. weißes Papier Verbindung v2 ERC20-Standard zur Darstellung von Kreditpositionen Interessanterweise wurde im Whitepaper nicht hervorgehoben, dass Compound v2 integriert ist in seine Smart Contracts integrieren. Aufgrund dieser Unterlassung waren die immensen Auswirkungen dieser Funktion möglicherweise nicht vorhersehbar. Belohnung 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 , verfolgt eine konservativere Risikomanagementstrategie und verteilt die Liquidität auf a für jeden leihbaren Vermögenswert. Das Design lässt auch Bedenken hinsichtlich der Benutzerfreundlichkeit und der Gaskosten erkennen. Veröffentlicht im Jahr 2022 Verbindung v3 Schwimmbad 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 enthalten: Versionshinweise 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 War , Nachfolger von ETHLend. Anstelle des Peer-to-Peer-Ansatzes von ETHLend führte Aave v1 einen gemeinsamen Liquiditätspool ein. Aave v1 im Oktober 2019 gestartet Wie in Yield v2 ist die hielt auch die Geschäftslogik. Der implementierte Buchhaltungs-, Risikomanagement- und Treasury-Funktionen. Die Bündelung des Treasury in einem einzigen Vertrag war ein Unterscheidungsmerkmal zu Compound v2. Router-Vertrag LendingPoolCore Die Entscheidung, die Besicherung zu belassen, erfolgt , 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 einen eigenen Vertrag 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 War . 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 (ähnlich den cTokens von Compound) und , die tokenisierte Schulden darstellen. Aave v2 veröffentlicht im Dezember 2021 aTokens vTokens 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 War 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. Aave v3 veröffentlicht im Januar 2023 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 War mit dem Ziel, Geldmärkte mit erlaubnisfreien Funktionen und minimaler Governance anzubieten. Euler im Dezember 2022 gestartet Ein Markenzeichen seines Designs ist das Muster. A . Auf diesen Speicher kann über „distinct“ zugegriffen werden , wobei jeder ein anderes konzeptionelles Element des Systems verwaltet. diamantartig Ein einziger Vertrag enthält den gesamten Speicher der Anwendung Proxys 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 Der Vertrag verwaltet Buchhaltungsvariablen. Lagerung Der Der Vertrag fungiert als Schatzkammer. BaseLogic Der Der Vertrag überwacht Variablen und Funktionen des Risikomanagements, einschließlich Besicherungsprüfungen. Risikomanager 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. Der Autor ist Mitbegründer und technischer Leiter bei Yield Protocol.