L'emprunt est une pierre angulaire des applications blockchain basées sur Ethereum. Avec des milliards d'actifs prêtés, il est essentiel pour les développeurs, les architectes ou les chercheurs de comprendre comment fonctionne l'emprunt.

Tout comme l'évolution des paradigmes de programmation, ces applications DeFi ont des conceptions architecturales diverses, reflétant des priorités changeantes allant de la sécurité à l'efficacité et à l'expérience de l'utilisateur.

Cette analyse porte sur l'architecture d'applications telles que MakerDAO, Compound, Aave, Euler et Yield. Nous mettrons en évidence les principales innovations et les modèles de conception, qui constituent des enseignements importants pour le développement des futures applications de prêt.

Si vous êtes développeur, architecte ou chercheur en sécurité, cet article est pour vous. À la fin, vous comprendrez facilement les nouvelles applications d'emprunt sur Ethereum, en saisissant leur architecture de manière rapide et complète. Découvrez comment ces géants de la finance sont construits de A à Z.

Emprunter à DeFi

La plupart des emprunts du DeFi sont surdimensionnés. Un utilisateur peut emprunter un actif spécifique s'il fournit une garantie d'une valeur supérieure au prêt. Contrairement aux prêts classiques, beaucoup de ces prêts ne sont pas assortis de remboursements réguliers ou de dates d'échéance fixes. En fait, vous pouvez emprunter et ne jamais rembourser.

Mais 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 est inférieure à ce montant, le prêt est liquidé.

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 qui suivent cette structure financière ont besoin des mêmes éléments de base, qui peuvent ensuite être agencés de différentes manières :

• Une trésorerie pour stocker les garanties des utilisateurs et les actifs empruntés
• Un système comptable qui suit les garanties et les dettes de chaque utilisateur.
• Fonctions qui déterminent le taux d'intérêt des emprunteurs
• Mécanisme permettant de vérifier si un prêt est suffisamment garanti, impliquant généralement des oracles de prix externes.
• Une voie de liquidation pour les prêts sous-collatéralisés
• Les systèmes de gestion des risques qui enregistrent les montants totaux empruntés et d'autres paramètres de sécurité, tels que les limites d'emprunt globales et par utilisateur, les garanties minimales et les ratios de surcollatéralisation spécifiques.
• Une interface permettant aux utilisateurs d'ajouter et de retirer des garanties, d'emprunter et de rembourser des actifs sous-jacents.

Processus d'emprunt dans MakerDAO. Toutes les applications partagent les mêmes étapes et les mêmes fonctions.

L'emprunt et le prêt peuvent être considérés comme des éléments distincts. Dans le DeFi, nous trouvons les deux caractéristiques dans la plupart des applications d'emprunt, mais elles ne sont pas toujours bien intégrées.

Dans Compound, Aave et Euler ils sont. Les taux d'intérêt pour les emprunteurs et les prêteurs sont en corrélation interne ; en fait, c'est ce qui permet à ces applications de fonctionner avec une intervention minimale.

En revanche, MakerDAO et Yield sont des initiateurs des actifs qu'ils prêtent aux emprunteurs.

Ils n'exigent pas des utilisateurs qu'ils fournissent des actifs pour que d'autres utilisateurs puissent emprunter.

Cet article se concentre sur l'emprunt sur la chaîne et ignore largement le prêt. L'emprunt est beaucoup plus compliqué en raison de l'exigence de garantie, et la compréhension du modèle d'emprunt permet généralement de mieux comprendre l'ensemble du protocole.

L'évolution architecturale de MakerDAO

Logo MakerDAO

MakerDAO, ancien en termes d'Ethereum, a été lancé sous sa forme actuelle en novembre 2019, et il détient 4,95 milliards de dollars de collatéral. Malgré son architecture modulaire avec des contrats distincts pour chaque fonction et une terminologie unique, il reste facile à comprendre et à vérifier.

La fonction de trésorerie de MakerDAO est gérée par les contrats Join.

Il existe un contrat distinct pour chaque jeton approuvé en tant qu'actif collatéral.

En revanche, MakerDAO ne possède pas de DAI, l'actif d'emprunt.

Au lieu de cela, il se contente de battre monnaie et de brûler des DAI en fonction des besoins.

La comptabilité est gérée dans le cadre du contrat vat.sol. Les jointures mettent à jour ce contrat lorsque des garanties entrent ou sortent du système. Si un utilisateur emprunte, il interagit directement avec le contrat vat.sol.

Cette action met à jour le solde de la dette de l'utilisateur et lui permet de frapper l'IAD à la jointure de l'IAD.

Pour rembourser, les utilisateurs brûlent le DAI dans le DAI Join. Ce processus met ensuite à jour la TVA, ce qui permet à l'utilisateur de régler son prêt.

En outre, le contrat vat.sol sert de moteur de gestion des risques. Il maintient des limites d'emprunt globales, fixe des seuils minimums par utilisateur et supervise les ratios de collatéralisation.

Lorsque des changements sont apportés au solde de la dette ou 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 sur le rapport entre le prix de l'IAD et celui de la garantie. 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 le coût de l'essence étaient secondaires, où l'expérience des utilisateurs était une préoccupation mineure et où la concurrence était négligeable.

Par conséquent, il peut sembler étrange, coûteux à utiliser et difficile à naviguer.

Pourtant, les vastes actifs qu'il gère et le fait qu'il ait fonctionné sans failles importantes soulignent la robustesse de sa conception et de son exécution.

Faits marquants :

• Chaque actif a son propre contrat dans la fonction de trésorerie à répartition maximale.
• La fonction comptable est centralisée au sein d'un contrat unique qui documente et applique également les paramètres de risque, y compris les contrôles de collatéralisation.
• Contrairement à d'autres applications, les oracles mettent à jour le contrat, en supervisant la collatéralisation.
• Les oracles de prix et de taux d'intérêt utilisent des interfaces distinctes
• Le taux d'intérêt est d'origine externe
• Pour emprunter, les utilisateurs doivent interagir avec plusieurs contrats

L'évolution architecturale du protocole Yield

Yield v1 a servi de preuve de concept pour les taux fixes en utilisant YieldSpace. Cette version a construit son moteur de dette collatéralisée au-dessus de MakerDAO. Cependant, Yield v1 était à la fois coûteux à utiliser et difficile à enrichir de nouvelles fonctionnalités.

Reconnaissant le potentiel de YieldSpace, nous avons rapidement commencé à développer Yield v2. Toujours inspiré par MakerDAO, mais désormais complètement indépendant, Yield v2 a été lancé en octobre 2021; Yield v2 a donné la priorité à la réduction des coûts de gaz et à l'amélioration de l'expérience des utilisateurs.

Le processus d'emprunt dans Yield v2, fortement influencé par MakerDAO

Tous les contrôles comptables, de gestion des risques et de collatéralisation ont été regroupés dans un seul contrat : le Cauldron. Conformément à l'approche de MakerDAO, nous avons réparti les fonctions de trésorerie entre les contrats Join, chacun d'eux étant consacré à un actif spécifique.

Nous avons revu l'intégration de nos oracles, en fusionnant les oracles de prix et de taux d'intérêt dans une interface commune. Nous avons inversé le flux d'oracles de MakerDAO de sorte que Cauldron consulte les oracles en fonction des besoins pour les contrôles de collatéralisation. À ma connaissance, c'est le flux préféré partout sauf chez MakerDAO.

L'introduction de la louche constitue un autre écart important par rapport à l'approche de MakerDAO. Ce contrat sert d'intermédiaire unique entre les utilisateurs et Yield. Il exerce un contrôle étendu sur la trésorerie et la comptabilité, mais en contrepartie, il offre une immense flexibilité pour le développement de fonctionnalités.

En résumé, emprunter dans le cadre de Yield v2 fonctionne de la manière suivante :

• Chaque actif dispose de son propre contrat de trésorerie, ce qui garantit une répartition maximale de la fonction de trésorerie.
• Un contrat unique centralise la fonction comptable. Ce contrat supervise également les mesures de gestion des risques et effectue des contrôles de collatéralisation.
• La fonction de collatéralisation consulte des oracles pour déterminer les prix et les taux d'intérêt.
• Les oracles de prix et de taux d'intérêt partagent une interface unifiée.
• Les taux d'intérêt sont générés de l'extérieur.
• Les utilisateurs peuvent emprunter en faisant une demande unique auprès d'un seul contrat.

L'évolution architecturale de la finance composée

La première version de Compound était une preuve de concept, démontrant qu'un marché monétaire pouvait être établi sur Ethereum. C'est pourquoi la simplicité a été privilégiée dans sa conception. Le contrat MoneyMarket.sol englobe toutes les fonctions, y compris le prêt.

Le processus d'emprunt dans le composé v1. Simple mais efficace.

• Les tâches de trésorerie, de comptabilité et de gestion des risques, telles que les contrôles de collatéralisation, sont regroupées dans un seul contrat.
• Ce contrat récupère les prix des oracles mais détermine les taux d'intérêt en fonction de l'utilisation des actifs.
• Les utilisateurs interagissent uniquement avec ce contrat, bien qu'ils doivent faire des appels distincts pour fournir des garanties et emprunter des actifs.

Composé v2

Compound v2 a été lancé en mai 2019, allumant l'ère de l'agriculture de rendement et inspirant d'innombrables bifurcations. Il fonctionnait lui aussi comme un marché monétaire, permettant aux utilisateurs de prêter et d'emprunter des actifs.

Sur la base de son livre blanc et de sa structure, il est évident que l'un des principaux objectifs de Compound v2 était d'utiliser la norme ERC20 pour représenter les positions de prêt. Cela a assuré la composabilité, permettant aux utilisateurs de prêter à Compound et d'utiliser ensuite ces positions porteuses d'intérêts dans d'autres applications de la blockchain.

Il est intéressant de noter que le livre blanc ne mentionne pas que Compound v2 intègre des récompenses dans ses contrats intelligents. Compte tenu de cette omission, l'immense impact de cette caractéristique n'a peut-être pas été prévu.

Le processus d'emprunt dans Compound v2. Première incursion dans les positions de prêt tokenisées.

• Chaque actif a son propre contrat de trésorerie, ce qui maximise la répartition de la fonction de trésorerie.
• La fonction comptable est également distribuée, chaque cToken indiquant les garanties et les dettes de l'utilisateur.
• Un contrat unique, le contrôleur, enregistre et applique les paramètres de gestion des risques, y compris les contrôles de collatéralisation.
• Le contrat responsable des contrôles de garantie fait référence aux oracles pour les prix et au cToken pour les taux d'intérêt.
• Les oracles des prix et des taux d'intérêt fonctionnent avec des interfaces différentes.
• Le taux d'intérêt découle en interne de l'utilisation des actifs.
• Les utilisateurs doivent interagir avec plusieurs contrats pour emprunter.

Composé v3

Publié en 2022, Compound v3 adopte une stratégie de gestion des risques plus conservatrice, en séparant les liquidités dans un pool pour chaque actif empruntable. La conception révèle également des préoccupations concernant la convivialité et les coûts du gaz.

Le processus d'emprunt dans Compound v3 (Comet). Revenir à l'essentiel, à la sécurité. Mais avec une meilleure interface utilisateur.

Le système est plus intuitif pour les développeurs et les utilisateurs grâce à la réduction du nombre d'appels nécessaires. En outre, la conception d'un contrat unique réduit les coûts de gaz en minimisant les appels entre les contrats. Les marchés monétaires distincts constituent une défense contre les attaques basées sur les oracles, qui constituent aujourd'hui une préoccupation majeure en matière de sécurité.

Parmi les autres fonctionnalités mentionnées dans les notes de mise à jour, on peut citer

• Un moteur de gestion des risques et de liquidation entièrement remanié. Cette conception renforce la sécurité des fonds tout en étant plus conviviale pour l'emprunteur.
• Fixer des limites sur le marché pour les différents actifs de garantie afin d'atténuer les risques.
• Les modèles de taux d'intérêt pour les revenus et les emprunts sont désormais distincts, la gouvernance ayant un contrôle total sur les politiques économiques.

Il est intéressant de noter que le composé v3 reprend l'architecture du composé v1 en confiant à un seul contrat toutes les fonctions pour chaque actif empruntable. Parmi les autres caractéristiques notables, citons

• Seuls les actifs prêtés peuvent être empruntés, ce qui n'est pas le cas des actifs garantis.
• Les garanties ne produisent pas de rendement dans le cadre de Compound v3.

L'interdiction d'emprunter des garanties renforce la sécurité de ceux qui les déposent. 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 résulter du 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 inférieures ou à 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, le fait d'interdire le prêt de garanties rend l'application sûre, ce qui est l'un des principaux objectifs de la v3.

D'un point de vue architectural :

• Chaque marché monétaire est un contrat individuel avec sa trésorerie, sa comptabilité et sa gestion des risques.
• Chaque marché monétaire conserve l'actif empruntable ainsi que tous ses jetons d'actifs collatéraux approuvés, ce qui entraîne une dispersion des actifs dans l'application.
• Les flux de prix sont le seul intrant externe ; les taux d'intérêt pour les emprunts et les prêts sont générés en interne.
• Les fonctions traditionnelles telles que l'approvisionnement/le retrait/l'emprunt/le remboursement ont été intelligemment consolidées. Or, retirer un actif empruntable d'un marché monétaire implique un emprunt, tandis que le fournir indique un remboursement ou un prêt sur la base de la dette de l'utilisateur
• Un contrat de routage est intégré, ce qui permet d'effectuer plusieurs opérations en un seul appel.

L'évolution architecturale d'Aave

Aave v1 a été lancée en octobre 2019, succédant à ETHLend. Au lieu de l'approche peer-to-peer d'ETHLend, Aave v1 a introduit un pool de liquidités partagé.

La procédure d'emprunt dans Aave v1. La mise en commun des liquidités est synonyme d'efficacité financière et informatique.

Comme dans Yield v2, le contrat de routeur contient également la logique commerciale. Le LendingPoolCore a mis en œuvre les fonctions de comptabilité, de gestion des risques et de trésorerie. La mise en commun de la trésorerie dans un contrat unique était un point de différenciation par rapport à Compound v2.

La décision de laisser les contrôles de collatéralisation dans son propre contrat, appelé à partir du routeur et non du contrat de comptabilité, semble faible, mais elle était probablement adaptée à l'objectif, car Aave v2 n'a été publié que deux ans après la version v1.

• Le contrat LendingPoolCore gère la trésorerie et la comptabilité.
• LendingPoolDataProvider gère les contrôles de collatéralisation et interagit avec l'oracle.
• LendingPool sert de point d'entrée à l'utilisateur et met en œuvre la logique commerciale.
• Les taux d'intérêt pour les emprunts et les prêts sont déterminés en interne, en se basant uniquement sur l'évolution des prix.

Aave v2

Aave v2 a été publié en décembre 2021. Tout en conservant des caractéristiques similaires à Aave v1, il a introduit une architecture améliorée et simplifiée par rapport à Aave v1 et Compound v2. Avec cette version, Aave a également introduit les aTokens (apparentés aux cTokens de Compound) et les vTokens, qui représentent la dette tokenisée.

Aave v2 a une architecture très propre, entièrement symbolisée.

Certaines fonctionnalités d'Aave v1, dont l'utilisation était limitée, ont été omises par souci de simplicité. Les problèmes rencontrés dans Aave v1, comme la représentation complexe des intérêts courus, ont été résolus dans Aave v2.

• Le contrat LendingPool consolide les fonctions globales de comptabilité et de gestion des risques, telles que les contrôles de collatéralisation. Il sert de point d'accès principal pour les utilisateurs
• aLes jetons représentent des garanties et s'apparentent à des positions de prêt. Les garanties des utilisateurs sont reflétées par les aTokens qu'ils détiennent, et la fonction de trésorerie est répartie entre tous les aTokens.
• Les vTokens sont utilisés pour représenter les positions de la dette. La dette d'un utilisateur est représentée par les vTokens qu'il détient

Aave v3

Aave v3 a été publié en janvier 2023 avec la prise en charge de plusieurs chaînes et d'autres fonctionnalités. Ces ajouts ne modifient pas l'architecture de base. La mise à jour permet également d'améliorer la gestion des risques et l'efficacité du gaz.

Malgré ses nombreuses avancées, pour les besoins de cette étude, Aave v3 n'est pas matériellement différent d'Aave v2. En fait, cela pourrait suggérer que l'architecture d'Aave v2 reste robuste en 2023.

L'évolution architecturale d'Euler

Euler a été lancé en décembre 2022, dans le but d'offrir des marchés monétaires avec des caractéristiques sans permission et une gouvernance minimale.

Le motif en forme de diamant est l'une des caractéristiques de son design. Un seul contrat contient tout le stockage de l'application. Ce stockage est accessible par l'intermédiaire de mandataires distincts, chacun gérant un élément conceptuel différent du système.

Même si un seul contrat stocke tous les actifs, la comptabilité et les données de gestion des risques, il existe toujours des eTokens pour les garanties et les prêts, et des dTokens pour les dettes, comme dans Aave v2. Toutefois, ces contrats de jetons ne sont que des vues du contrat de stockage central.

• Le contrat de stockage gère les variables comptables.
• Le contrat BaseLogic fait office de trésorerie.
• Le contrat du RiskManager supervise les variables et les fonctions de gestion des risques, y compris les contrôles de collatéralisation.

Une analyse du code révèle que le coût minimal du gaz était une priorité, ce qui a conduit à une 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 a été répartie entre différents modules, servant à la mise en œuvre du contrat de stockage, qui a agi principalement comme un contrat de procuration.

Cette conception unifiée facilite également les mises à niveau. Les modules peuvent être rapidement remplacés pour modifier ou introduire des fonctionnalités si aucun changement de stockage n'est nécessaire.

Euler a été piraté quinze mois après sa sortie et six mois après que la mise à jour a 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'agit plutôt d'une surveillance insuffisante des mises à jour du code.

Conclusion

Le plus dur est fait, passons en revue ce que nous avons appris

Les premières applications Ethereum telles que MakerDAO, Compound et Aave ont montré le potentiel de l'emprunt surcollatéralisé sur Ethereum. Une fois que ces preuves de concept se sont avérées concluantes, l'accent a été mis sur l'introduction d'un ensemble de nouvelles fonctionnalités afin de 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 mise en commun des liquidités, qui ont prospéré en particulier dans les conditions de marché haussières.

L'introduction par Compound v2 de positions de prêt tokenisées, qui permettent à ces positions d'être reconnues comme des actifs standard par d'autres applications, a constitué un développement important. Aave v2 et Euler sont allés plus loin en mettant en place des positions de dette tokenisées, dont l'utilité plus large reste un sujet de débat.

Le coût élevé du gaz est devenu une préoccupation majeure pendant le marché haussier, ce qui a entraîné des modifications de l'expérience utilisateur, comme on peut le voir dans Yield v2, Aave v2 et Euler. Les contrats de routeur et les implémentations monolithiques ont contribué à réduire les coûts supportés par les utilisateurs pour les transactions. Toutefois, 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és pour mieux se prémunir contre d'éventuels piratages. 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'emprunts garantis.

Dans cet article, je vous propose une vue d'ensemble des principales applications d'emprunts garantis sur Ethereum. L'approche que j'ai employée pour analyser chaque demande peut également être appliquée pour comprendre rapidement les subtilités d'autres demandes d'emprunts garantis.

Lorsque vous développez une application d'emprunt par blockchain, pensez toujours au stockage des actifs, à l'emplacement des documents comptables et aux méthodes d'évaluation des risques et des garanties. Au fur et à mesure de l'examen de ces questions, vous pouvez vous appuyer sur l'historique des demandes précédentes et sur les informations fournies dans cette vue d'ensemble pour prendre des décisions éclairées.

Nous vous remercions de votre lecture et vous souhaitons bonne chance.

Merci à Calnix pour la révision et l'édition de cet article.

Clause de non-responsabilité：

1. Cet article est repris de[hackernoon]. Tous les droits d'auteur appartiennent à l'auteur original[alcueca]. Si vous avez des objections à cette réimpression, veuillez contacter l'équipe de Gate Learn, qui s'en chargera rapidement.
2. Clause de non-responsabilité : Les points de vue et les opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent pas un conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe de Gate Learn. Sauf mention contraire, il est interdit de copier, distribuer ou plagier les articles traduits.