Emprunter sur Ethereum : comparaison de l'évolution de l'architecture de MakerDAO, Yield, Aave, Compound et Euler

. Avec , comprendre le fonctionnement de l’emprunt est crucial pour les promoteurs, les architectes ou les chercheurs. L'emprunt est la pierre angulaire des applications blockchain basées sur Ethereum des milliards d'actifs prêtés 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 , , , , et . Nous mettrons en évidence les principales innovations et modèles de conception, qui constituent des enseignements importants pour le développement de futures applications de prêt. CréateurDAO Composé Aave Euler Rendement 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. Emprunter dans DeFi La plupart des emprunts DeFi sont . 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 conventionnels, bon nombre de ces prêts n’ont pas de remboursements réguliers ni de dates d’échéance fixes. Essentiellement, vous pouvez emprunter et ne jamais rembourser. surdimensionné 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 . 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 suivant cette structure financière nécessitent les mêmes éléments de base, qui peuvent ensuite être organisés de plusieurs 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 Un mécanisme pour 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-garantis Systèmes de gestion des risques qui enregistrent les montants totaux empruntés et d'autres mesures de sécurité, telles que les limites d'emprunt globales et par utilisateur, les minimums de garantie et les ratios de surdimensionnement spécifiques. Une interface permettant aux utilisateurs d'ajouter et de supprimer des garanties, d'emprunter et de rembourser le sous-jacent 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 . 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. Dans Compound, Aave et Euler, ce sont sont les initiateurs des actifs qu'ils prêtent aux emprunteurs. D'autre part, MakerDAO et Yield . 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. L'évolution architecturale de MakerDAO , ancien en termes Ethereum, et ça tient . Malgré son architecture modulaire avec des contrats distincts pour chaque fonction et une terminologie unique, elle reste facile à comprendre et à vérifier. CréateurDAO , a été lancé sous sa forme actuelle en novembre 2019 4,95 milliards de dollars de garantie La fonction de trésorerie dans MakerDAO est gérée par le Rejoindre contrats. Il y a un pour chaque jeton approuvé comme actif de garantie. contrat séparé A l’inverse, MakerDAO ne possède aucun DAI, l’actif d’emprunt. Au lieu de cela, il s'agit simplement comme demandé. menthes et brûlures DAI La comptabilité est gérée au sein du contracter. Les jointures lorsque la garantie entre ou sort du système. Si un utilisateur emprunte, il . .sol tva mettre à jour ce contrat interagir directement avec le contrat tva.sol 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 sert de moteur. Il maintient les limites d'emprunt mondiales, fixe des seuils minimaux par utilisateur et supervise les ratios de garantie. vat.sol gestion des risques 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 - , l'expérience utilisateur était une préoccupation mineure et la concurrence était négligeable. une époque où des facteurs tels que les coûts du gaz étaient secondaires 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: 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 garantie. Contrairement à d'autres applications, les oracles mettent à jour le contrat et supervisent la garantie. Les oracles des prix et des taux d’intérêt utilisent des interfaces distinctes Le taux d’intérêt provient de l’extérieur Pour emprunter, les utilisateurs doivent interagir avec plusieurs contrats L'évolution architecturale du protocole de rendement a servi de preuve de concept pour les tarifs fixes en utilisant . Cette version a construit son moteur de dette garantie au-dessus de MakerDAO. Cependant, Yield v1 était à la fois coûteux à utiliser et difficile à augmenter avec de nouvelles fonctionnalités. Rendement v1 RendementEspace Conscients du potentiel de YieldSpace, nous sommes rapidement passés au développement . Toujours inspiré de MakerDAO, mais désormais totalement indépendant, Yield v2 ; Yield v2 a donné la priorité à la réduction des coûts du gaz et à une expérience utilisateur améliorée. Rendement v2 lancé en octobre 2021 Tous les contrôles de comptabilité, de gestion des risques et de garantie ont été regroupés en un seul contrat : le . En miroir de l'approche de MakerDAO, nous avons réparti les fonctions de trésorerie entre contrats, chacun dédié à un actif spécifique. Chaudron Rejoindre Nous avons réorganisé notre intégration Oracle, en fusionnant les oracles de prix et de taux d'intérêt dans un . Nous avons inversé le flux oracle de MakerDAO de telle sorte que Cauldron au besoin pour les contrôles de garantie. À ma connaissance, c'est le flux préféré partout sauf MakerDAO. interface commune consulte les oracles Un autre écart significatif par rapport à l'approche de MakerDAO a été notre introduction du . 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é, . Louche mais offre en retour une immense flexibilité pour le développement de fonctionnalités En résumé, emprunter dans Yield v2 fonctionne comme suit : Chaque actif dispose de son propre contrat de trésorerie dédié, assurant 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 garantie. La fonction de collatéralisation consulte des oracles pour déterminer les prix et les taux d’intérêt. Les oracles des prix et des taux d’intérêt partagent une interface unifiée. Les taux d’intérêt sont générés à l’extérieur. Les utilisateurs peuvent emprunter en effectuant une seule demande sur un seul contrat. L’évolution architecturale de la finance composée Le était un , démontrant qu’un marché monétaire pourrait être établi sur Ethereum. C’est pour cette raison que la simplicité a été privilégiée dans sa conception. Le Le contrat englobe toutes les fonctions, y compris le prêt. première version de Composé Preuve de concept MoneyMarket.sol Les tâches de trésorerie, de comptabilité et de gestion des risques, telles que les contrôles de garantie, 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 effectuer des appels séparés pour fournir des garanties et emprunter des actifs. Composé v2 , déclenchant l’ère de l’agriculture de rendement et inspirant d’innombrables fourchettes. Il fonctionnait également comme un marché monétaire, permettant aux utilisateurs de prêter et d’emprunter des actifs. Compound v2 a été lancé en mai 2019 Basé sur son et la structure, il est évident qu'un objectif majeur pour était d'utiliser le . Cela garantissait la composabilité, permettant aux utilisateurs de prêter à Compound, puis d'utiliser ces positions portant intérêt dans d'autres applications blockchain. papier blanc Composé v2 Norme ERC20 pour représenter les positions de prêt Il est intéressant de noter que le livre blanc n'a pas souligné que le composé v2 incorporait dans ses contrats intelligents. Compte tenu de cette omission, l’immense impact de cette fonctionnalité n’aurait peut-être pas été prévu. récompenses Chaque actif dispose de son propre contrat de trésorerie, maximisant la répartition de la fonction de trésorerie. La fonction comptable est également distribuée, chaque cToken notant 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 garantie. Le contrat responsable des contrôles de collatéralisation 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 différentes interfaces. Le taux d’intérêt dérive en interne de l’utilisation des actifs. Les utilisateurs doivent interagir avec plusieurs contrats pour emprunter. Composé v3 , adopte une stratégie de gestion des risques plus conservatrice, en séparant la liquidité en un pour chaque actif empruntable. La conception révèle également des préoccupations concernant la convivialité et les coûts du gaz. Sorti en 2022 Composé v3 piscine 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 inclure: notes de version Un moteur de gestion des risques et de liquidation entièrement repensé. Cette conception améliore la sécurité des fonds tout en étant plus conviviale pour les emprunteurs. Fixez des limites sur l’ensemble du marché pour les actifs de garantie individuels 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 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 : Seuls les actifs prêtés peuvent être empruntés ; les actifs collatéraux ne le peuvent pas. La garantie ne produit pas de rendement dans Compound v3. 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 : 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 de garantie approuvés, ce qui entraîne la dispersion des actifs dans l'application. Les flux de prix constituent 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. Désormais, retirer un actif empruntable d'un marché monétaire implique un emprunt, tandis que le fournir implique un remboursement ou un prêt en fonction de la dette de l'utilisateur. Un contrat de routage est intégré, permettant plusieurs opérations en un seul appel L'évolution architecturale d'Aave était , succédant à ETHLend. Au lieu de l'approche peer-to-peer d'ETHLend, Aave v1 a introduit un pool de liquidité partagé. Aave v1 lancé en octobre 2019 Comme dans Yield v2, le détenait également la logique métier. Le 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 seul contrat était un point différenciant du Compound v2. contrat de routeur LendingPoolCore La décision de laisser la garantie s’enregistre , appelé depuis le routeur et non depuis le contrat comptable semble faible, mais il était probablement adapté à son objectif car Aave v2 n'a été publié que deux ans après la sortie de la v1. son propre contrat Le contrat LendingPoolCore gère la trésorerie et la comptabilité LendingPoolDataProvider gère les contrôles de garantie et interagit avec l'oracle LendingPool sert de point d'entrée utilisateur et implémente la logique métier Les taux d'intérêt pour les emprunts et les prêts sont déterminés en interne, en fonction uniquement des informations sur les prix. Aave v2 était . Bien qu'il ait conservé des fonctionnalités similaires à Aave v1, il a introduit une architecture améliorée et plus simple par rapport à Aave v1 et Compound v2. Avec cette version, Aave a également introduit (semblable aux cTokens de Compound) et , qui représentent une dette symbolique. Aave v2 sorti en décembre 2021 aJetons Jetons virtuels 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. Le contrat LendingPool consolide les fonctions globales de comptabilité et de gestion des risques, telles que les contrôles de garantie. Il sert de point d'accès principal pour les utilisateurs Les aTokens représentent une garantie et s'apparentent à des positions de prêt. La garantie des utilisateurs se reflète dans leurs avoirs aToken, et la fonction de trésorerie est répartie sur tous les aTokens. Les vTokens sont utilisés pour représenter les positions de dette. La dette d'un utilisateur est représentée par les vTokens qu'il détient Aave v3 était avec prise en charge multi-chaînes et d'autres fonctionnalités. Ces ajouts ne modifient pas l'architecture de base. La mise à jour offre également une gestion des risques et une efficacité énergétique améliorées. Aave v3 sorti en janvier 2023 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. L'évolution architecturale d'Euler était , visant à offrir des marchés monétaires avec des fonctionnalités sans autorisation et une gouvernance minimale. Euler lancé en décembre 2022 Une caractéristique de sa conception est le modèle. UN . Ce stockage est accessible via des , chacun gérant un élément conceptuel différent du système. semblable à un diamant un seul contrat contient tout le stockage de l'application procurations 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. Le le contrat gère les variables comptables. Stockage Le Le contrat fait office de trésorerie. BaseLogique Le Le contrat supervise les variables et les fonctions de gestion des risques, y compris les contrôles de garantie. Gestionnaire des risques 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 Conclusion 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 à Calnix pour avoir révisé et édité cet article. L'auteur est co-fondateur et responsable technique chez Yield Protocol.