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.
L'emprunt est la pierre angulaire des applications blockchain basées sur Ethereum . Avec
Tout comme l'évolution des paradigmes de programmation, ces applications DeFi ont des conceptions architecturales diverses, reflétant l'évolution des priorités allant de la sécurité à l'efficacité et à l'expérience utilisateur.
Cette analyse porte sur l'architecture d'applications telles que
Si vous êtes développeur, architecte ou chercheur en sécurité, cet article est fait pour vous. À la fin, vous comprendrez facilement les nouvelles applications d’emprunt sur Ethereum, en appréhendant leur architecture de manière rapide et complète. Plongez pour voir comment ces géants DeFi sont construits à partir de zéro.
La plupart des emprunts DeFi sont
Cependant, il y a un hic.
La valeur de la garantie doit toujours dépasser la valeur du prêt d'une marge prédéterminée .
Si la valeur de la garantie tombe en dessous de ce montant, le prêt est
Lors de la liquidation, quelqu’un d’autre rembourse une partie ou la totalité de votre prêt et reçoit en retour une partie ou la totalité de votre garantie.
Toutes les demandes d’emprunt suivant cette structure financière nécessitent les mêmes éléments de base, qui peuvent ensuite être organisés de plusieurs manières :
Processus d'emprunt dans MakerDAO. Toutes les applications partagent les mêmes étapes et fonctions.
L’emprunt et le prêt peuvent être considérés comme des éléments distincts. Dans DeFi, on retrouve les deux fonctionnalités dans la plupart des applications d’emprunt, mais elles ne sont pas toujours bien intégrées .
Dans Compound, Aave et Euler, ce sont . Les taux d’intérêt des emprunteurs et des prêteurs sont corrélés en interne ; en fait, c'est ce qui permet à ces applications de fonctionner avec une intervention minimale.
D'autre part, MakerDAO et Yield sont les initiateurs des actifs qu'ils prêtent aux emprunteurs.
Ils n'exigent pas que les utilisateurs fournissent des actifs pour que d'autres utilisateurs puissent emprunter .
Cet article se concentrera sur les emprunts en chaîne et ignorera largement les prêts. L'emprunt est beaucoup plus compliqué en raison de l'exigence de garantie, et comprendre le modèle d'emprunt permet généralement de mieux comprendre l'ensemble du protocole.
Logo MakerDAO
La fonction de trésorerie dans MakerDAO est gérée par le
Il y a un
A l’inverse, MakerDAO ne possède aucun DAI, l’actif d’emprunt.
Au lieu de cela, il s'agit simplement
La comptabilité est gérée au sein du
Cette action met à jour le solde de la dette de l'utilisateur et lui permet de créer du DAI lors de la jointure DAI.
Pour rembourser, les utilisateurs gravent le DAI dans le DAI Join. Ce processus met ensuite à jour la TVA, permettant à l'utilisateur de régler son prêt .
De plus, le contrat vat.sol
sert de
Lorsque des modifications sont apportées à la dette ou au solde de la garantie d'un utilisateur, le contrat vat.sol évalue à la fois le taux et le spot.
Il s’agit du taux d’intérêt basé sur la garantie utilisée et du ratio prix DAI/garantie en vigueur. Il est intéressant de noter que ces valeurs sont introduites dans le contrat vat.sol par d'autres contrats MakerDAO, une méthode distincte de la plupart des autres applications.
MakerDAO a donné la priorité à la sécurité lors de sa phase de conception - une époque où des facteurs tels que les coûts du gaz étaient secondaires , l'expérience utilisateur était une préoccupation mineure et la concurrence était négligeable.
Par conséquent, il peut sembler original, coûteux à utiliser et difficile à naviguer.
Pourtant, les vastes actifs qu’elle gère et son historique de fonctionnement sans failles significatives soulignent sa conception et son exécution robustes.
Points forts:
Conscients du potentiel de YieldSpace, nous sommes rapidement passés au développement
Le processus d'emprunt dans Yield v2, fortement influencé par MakerDAO
Tous les contrôles de comptabilité, de gestion des risques et de garantie ont été regroupés en un seul contrat : le
Nous avons réorganisé notre intégration Oracle, en fusionnant les oracles de prix et de taux d'intérêt dans un
Un autre écart significatif par rapport à l'approche de MakerDAO a été notre introduction du
En résumé, emprunter dans Yield v2 fonctionne comme suit :
Le
Le processus d’emprunt dans Compound v1. Simple mais efficace.
Basé sur son
Il est intéressant de noter que le livre blanc n'a pas souligné que le composé v2 incorporait
Le processus d’emprunt dans Compound v2. Première incursion dans les positions de prêt tokenisées.
Le processus d'emprunt dans Compound v3 (Comet). Retour aux sources, retour à la sécurité. Avec une meilleure UX, cependant.
Le système est plus intuitif tant pour les développeurs que pour les utilisateurs en raison de la réduction du nombre d'appels requis. De plus, la conception unique du contrat réduit les coûts du gaz en minimisant les appels entre les contrats. Les marchés monétaires séparés constituent une défense contre les attaques basées sur Oracle, qui constituent désormais un problème de sécurité majeur.
Autres fonctionnalités pertinentes mentionnées dans le
Il est intéressant de noter que Composé v3 reflète l'architecture de Composé v1 en ayant un seul contrat gérant toutes les fonctions pour chaque actif empruntable. D'autres caractéristiques notables incluent :
L’interdiction d’emprunter des garanties renforce la sécurité de ceux qui déposent les garanties. Cela réduit la probabilité que des erreurs de gouvernance ou des attaques intentionnelles mettent en péril la garantie.
L'élimination des rendements sur les garanties fournies pourrait être due au fait que Compound a réussi à accumuler beaucoup de liquidités dans la v2. J'ai l'intuition que dans Compound v2 les limites d'emprunt étaient soit inférieures, soit à peine supérieures aux actifs prêtés à l'application par les utilisateurs.
En supposant qu’ils gèrent des niveaux de liquidité similaires pour la v3, interdire le prêt de garanties rend l’application sûre, l’un des principaux objectifs de la v3.
D'un point de vue architectural :
Le processus d’emprunt dans Aave v1. La liquidité mise en commun signifiait une efficacité financière et informatique.
Comme dans Yield v2, le
La décision de laisser la garantie s’enregistre
Aave v2 a une architecture très propre, entièrement tokenisée.
Certaines fonctionnalités d'Aave v1, dont l'utilité était limitée, ont été omises par souci de simplicité. Les problèmes d'Aave v1, comme la représentation complexe des intérêts courus, ont été résolus dans Aave v2.
Malgré ses nombreuses avancées, aux fins de cette étude, Aave v3 n’est pas sensiblement différent d’Aave v2. En fait, cela pourrait suggérer que l’architecture d’Aave v2 reste robuste en 2023.
Une caractéristique de sa conception est le
Même si un contrat stocke toutes les données sur les actifs, la comptabilité et la gestion des risques, il existe toujours des eTokens pour les garanties et les prêts, et des dTokens pour la dette, similaires à Aave v2. Cependant, ces contrats symboliques ne sont que des vues du contrat de stockage central.
Une analyse du code révèle que le coût minimal du gaz était une priorité, ce qui a conduit à la conception monolithique éliminant le besoin d'appels inter-contrats. La sécurité a été assurée par des tests et des audits rigoureux. Seule la logique était répartie entre différents modules, servant d'implémentation au contrat de stockage, qui servait principalement de contrat proxy.
Cette conception unifiée prend également en charge des mises à niveau faciles. Les modules peuvent être rapidement remplacés pour modifier ou introduire des fonctionnalités si aucune modification du stockage n'est requise .
Euler a été piraté quinze mois après sa sortie et six mois après que la mise à jour ait introduit la vulnérabilité exploitée.
Je ne pense pas que l’architecture monolithique ait joué un rôle dans l’épuisement des actifs ; il s'agissait plutôt d'une surveillance insuffisante des mises à jour du code .
Le travail acharné est terminé, passons en revue ce que nous avons appris
Les premières applications Ethereum telles que MakerDAO, Compound et Aave ont montré le potentiel des emprunts surgarantis sur Ethereum. Une fois ces preuves de concept couronnées de succès, l’accent a été mis sur l’introduction d’un mélange de nouvelles fonctionnalités pour conquérir des parts de marché. Les versions ultérieures de Compound et d'Aave ont introduit l'agriculture de rendement, la composabilité et la liquidité mutualisée, qui ont prospéré en particulier dans des conditions de marché haussières.
Un développement important a été l'introduction par Compound v2 de positions de prêt tokenisées, qui ont permis à ces positions d'être reconnues comme actifs standard par d'autres applications. Aave v2 et Euler sont allés plus loin en mettant en œuvre des positions de dette symbolique, dont l'utilité plus large reste un sujet de débat.
Les coûts élevés du gaz sont apparus comme une préoccupation majeure au cours du marché haussier, entraînant des modifications de l'expérience utilisateur, comme le montrent Yield v2, Aave v2 et Euler. Les contrats de routeurs et les implémentations monolithiques ont contribué à réduire les coûts supportés par les utilisateurs pour les transactions. Cependant, cela s’est fait au détriment d’un code plus complexe, et par conséquent plus risqué.
Le composé v3 semble créer un précédent, en donnant la priorité à la sécurité plutôt qu'à l'efficacité financière. Il s’écarte du modèle traditionnel de pool de liquidité pour mieux se protéger contre les piratages potentiels. L’essor des réseaux L2, où les coûts du gaz deviennent de plus en plus négligeables, façonnera probablement la conception des futures applications d’emprunt garanti.
Dans cet article, j'ai fourni un aperçu complet des principales applications d'emprunt garanti sur Ethereum. L'approche que j'ai utilisée pour analyser chaque demande peut également être appliquée pour saisir rapidement les subtilités d'autres demandes d'emprunt garanti.
Lors du développement d’une application d’emprunt blockchain, tenez toujours compte du stockage des actifs, du placement des documents comptables et des méthodes d’évaluation des risques et des garanties. Pendant que vous étudiez ces considérations, tirez parti de l’historique des candidatures précédentes et des enseignements de cet aperçu pour éclairer vos décisions.
Merci d'avoir lu et bonne chance.
Grâce à
L'auteur est co-fondateur et responsable technique chez Yield Protocol.
Emprunter sur Ethereum : comparaison de l'évolution de l'architecture de MakerDAO, Yield, Aave, Compound et Euler | HackerNoon