Hello. I design and build blockchain solutions. I like to make the complex simple.
Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.
This story contains new, firsthand information uncovered by the writer.
The writer was physically present in relevant location(s) to this story. The location is also a prevalent aspect of this story be it news or otherwise.
Kreditaufnahme ist ein Eckpfeiler von Ethereum-basierten Blockchain-Anwendungen . Mit
Ä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
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.
Die meisten DeFi-Kredite sind
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
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:
Ausleihvorgang in MakerDAO. Alle Anwendungen haben die gleichen Schritte und Funktionen.
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.
MakerDAO-Logo
Die Treasury-Funktion in MakerDAO wird von verwaltet
Da ist ein
Im Gegensatz dazu verfügt MakerDAO über keinen DAI, den leihenden Vermögenswert.
Stattdessen ist es lediglich
Die Buchhaltung erfolgt innerhalb der
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
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:
Da wir das Potenzial von YieldSpace erkannten, begannen wir schnell mit der Entwicklung
Der Kreditaufnahmeprozess in Yield v2 wird stark von MakerDAO beeinflusst
Alle Buchhaltungs-, Risikomanagement- und Besicherungsprüfungen wurden in einem Vertrag zusammengefasst: dem
Wir haben unsere Oracle-Integration überarbeitet und Preis- und Zinsorakel zu einem zusammengeführt
Eine weitere wesentliche Abweichung vom Ansatz von MakerDAO war unsere Einführung des
Zusammenfassend funktioniert die Kreditaufnahme in Yield v2 wie folgt:
Der
Der Ausleihvorgang in Compound v1. Einfach und doch effektiv.
Basierend auf seiner
Interessanterweise wurde im Whitepaper nicht hervorgehoben, dass Compound v2 integriert ist
Der Ausleihvorgang in Compound v2. Erster Ausflug in tokenisierte Kreditpositionen.
Der Ausleihvorgang in Compound v3 (Comet). Zurück zu den Grundlagen, zurück zur Sicherheit. Allerdings mit besserer UX.
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
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:
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:
Der Ausleihvorgang in Aave v1. Gebündelte Liquidität bedeutete finanzielle und rechnerische Effizienz.
Wie in Yield v2 ist die
Die Entscheidung, die Besicherung zu belassen, erfolgt
Aave v2 hat eine sehr saubere Architektur, vollständig tokenisiert.
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.
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.
Ein Markenzeichen seines Designs ist das
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.
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 .
Die harte Arbeit ist erledigt, lassen Sie uns noch einmal Revue passieren lassen, was wir gelernt haben
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
Der Autor ist Mitbegründer und technischer Leiter bei Yield Protocol.
Anleihen bei Ethereum: Vergleich der Architekturentwicklung von MakerDAO, Yield, Aave, Compound und Euler | HackerNoon