Kreditaufnahme ist ein Eckpfeiler von Ethereum-basierten Blockchain-Anwendungen. Da Vermögenswerte in Milliardenhöhe ausgeliehen werden, ist es für Entwickler, Architekten oder Forscher von entscheidender Bedeutung zu verstehen, wie die Kreditaufnahme funktioniert.

Ä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, Compound, Aave, Euler und Yield. 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, kommt es zur Liquidation des Darlehens.

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

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 es. 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-Logo

MakerDAO, ein für Ethereum uraltes Unternehmen, wurde in seiner aktuellen Form im November 2019 eingeführt und verfügt über 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 durch die Join- Verträge verwaltet.

Für jeden als Sicherheit genehmigten Token gibt es einen separaten Vertrag .

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

Stattdessen werden DAI lediglich nach Bedarf geprägt und verbrannt .

Die Abrechnung erfolgt im Rahmen des vat.sol -Vertrags. Die Joins aktualisieren diesen Vertrag , wenn Sicherheiten in das System gelangen oder es verlassen. Wenn ein Benutzer Kredite aufnimmt, interagiert er direkt mit dem vat.sol-Vertrag.

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 Join. 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- Engine. 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 seine Betriebsbilanz ohne nennenswerte Verstöße, 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 Orakel 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

Yield v1 diente als Proof of Concept für Festzinsen mit 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, gingen wir schnell zur Entwicklung von Yield v2 über. Immer noch von MakerDAO inspiriert, aber jetzt völlig unabhängig, wurde Yield v2 im Oktober 2021 eingeführt; Bei Yield v2 standen reduzierte Gaskosten und ein verbessertes Benutzererlebnis im Vordergrund.

Der Kreditaufnahmeprozess in Yield v2 wird stark von MakerDAO beeinflusst

Alle Buchhaltungs-, Risikomanagement- und Besicherungsprüfungen wurden in einem Vertrag zusammengefasst: dem Cauldron. In Anlehnung an den Ansatz von MakerDAO haben wir die Treasury-Funktionen auf Join- Verträge verteilt, von denen jeder einem bestimmten Vermögenswert gewidmet ist.

Wir haben unsere Oracle-Integration überarbeitet und Preis- und Zinsorakel in einer gemeinsamen Schnittstelle zusammengeführt. Wir haben den Orakelfluss von MakerDAO umgekehrt, sodass Cauldron bei Bedarf Orakel für Besicherungsprüfungen konsultiert . Meines Wissens ist dies überall außer MakerDAO der bevorzugte Ablauf.

Eine weitere wesentliche Abweichung vom Ansatz von MakerDAO war unsere Einführung des Ladle. 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 bei der 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

Die erste Version von Compound war ein Proof-of-Concept, der zeigte, dass ein Geldmarkt auf Ethereum eingerichtet werden könnte. Aus diesem Grund wurde beim Design Wert auf Einfachheit gelegt. Der MoneyMarket.sol- Vertrag kapselt alle Funktionen, einschließlich der Kreditvergabe.

Der Ausleihvorgang in Compound v1. Einfach und doch effektiv.

• 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 auf den Markt gebracht, 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 seinem Whitepaper und seiner Struktur ist es offensichtlich, dass ein Hauptziel von Compound v2 darin bestand, den ERC20-Standard zur Darstellung von Kreditpositionen 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.

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

Der Ausleihvorgang in Compound v2. Erster Ausflug in tokenisierte Kreditpositionen.

• 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

Compound v3wurde 2022 veröffentlicht und verfolgt eine konservativere Risikomanagementstrategie, bei der die Liquidität für jeden leihbaren Vermögenswert in einen Pool aufgeteilt wird. Das Design lässt auch Bedenken hinsichtlich der Benutzerfreundlichkeit und der Gaskosten erkennen.

Der Ausleihvorgang in Compound v3 (Comet). Zurück zum Wesentlichen, 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 der Abwehr von Orakel-basierten Angriffen, die mittlerweile ein großes Sicherheitsrisiko darstellen.

Weitere relevante Funktionen, die in den Versionshinweisen erwähnt werden, sind:

• 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 unter oder nicht viel höher lagen 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, der mehrere Vorgänge in einem einzigen Anruf ermöglicht

Die architektonische Entwicklung von Aave

Aave v1 wurde im Oktober 2019 als Nachfolger von ETHLend eingeführt. Anstelle des Peer-to-Peer-Ansatzes von ETHLend führte Aave v1 einen gemeinsamen Liquiditätspool ein.

Der Ausleihvorgang in Aave v1. Gebündelte Liquidität bedeutete finanzielle und rechnerische Effizienz.

Wie in Yield v2 enthielt der Router-Vertrag 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 Besicherungsprüfungen in einem eigenen Vertrag zu belassen, der vom Router aufgerufen wird, und nicht im Abrechnungsvertrag, erscheint schwach, 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 wurde im Dezember 2021 veröffentlicht. 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 führte Aave auch aTokens (ähnlich den cTokens von Compound) und vTokens ein, die tokenisierte Schulden darstellen.

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.

• 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 wurde im Januar 2023 mit Multi-Chain-Unterstützung und anderen Funktionen veröffentlicht . 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 wurde im Dezember 2022 mit dem Ziel gegründet, Geldmärkte mit erlaubnisfreien Funktionen und minimaler Governance anzubieten.

Ein Markenzeichen seines Designs ist das rautenartige Muster. Ein einziger Vertrag umfasst den gesamten Speicher der Anwendung. Auf diesen Speicher kann über verschiedene Proxys zugegriffen werden, die jeweils ein anderes konzeptionelles Element des Systems verwalten.

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 Speichervertrag verwaltet Abrechnungsvariablen.
• Der BaseLogic- Vertrag fungiert als Treasury.
• Der RiskManager- Vertrag überwacht Risikomanagementvariablen und -funktionen, 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 der Einführung der ausgenutzten Schwachstelle durch das Upgrade gehackt.

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

Abschluss

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 stellten während des Bullenmarkts ein großes Problem dar 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.

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

Haftungsausschluss:

1. Dieser Artikel wurde von [hackernoon] nachgedruckt. Alle Urheberrechte liegen beim ursprünglichen Autor [alcueca]. Wenn Sie Einwände gegen diesen Nachdruck haben, wenden Sie sich bitte an das Gate Learn- Team, das sich umgehend darum kümmern wird.
2. Haftungsausschluss: Die in diesem Artikel geäußerten Ansichten und Meinungen sind ausschließlich die des Autors und stellen keine Anlageberatung dar.
3. Übersetzungen des Artikels in andere Sprachen werden vom Gate Learn-Team durchgeführt. Sofern nicht anders angegeben, ist das Kopieren, Verbreiten oder Plagiieren der übersetzten Artikel verboten.