Interprétation approfondie de l’évolution de l’architecture des applications de prêt sur Ethereum

Auteur: @albertocuestacanada

Traduction : Communauté Dengchain

! [Interprétation approfondie de l’évolution de l’architecture des applications de prêt sur Ethereum] (https://cdn-img.panewslab.com//panews/2022/10/15/images/bcdcc4b76ff94a8c3e73b9d3d124dc11.png) Évolution des produits de prêt

Le prêt est la pierre angulaire des applications blockchain basées sur Ethereum. Des milliards d’actifs ont déjà été prêtés[5] Il est donc crucial pour les promoteurs, les architectes ou les chercheurs de comprendre le fonctionnement des prêts.

À l’instar de l’évolution des paradigmes de programmation, ces applications DeFi ont des conceptions architecturales différentes qui reflètent l’évolution des priorités allant de la sécurité à l’expérience utilisateur efficace.

Cet article se penche sur l’analyse de l’architecture des applications de prêt telles que MakerDAO, Compound, Aave, Euler et Yield. Nous mettrons en évidence les innovations clés et les modèles de conception qui sont des leçons importantes pour le développement futur d’applications de prêt.

Si vous êtes un développeur, un architecte ou un chercheur en sécurité, cet article est fait pour vous. Enfin, vous découvrirez facilement la nouvelle application de prêt sur Ethereum et aurez une compréhension rapide et complète de son architecture. Apprenez-en plus sur la façon dont ces géants de la DeFi ont été construits à partir de zéro.

Prêt dans la DeFi

La plupart des prêts DeFi sont surgarantis[6] 。 Si la valeur de la garantie fournie par l’utilisateur est supérieure à la valeur du prêt, l’utilisateur peut emprunter un actif spécifique. Contrairement aux prêts traditionnels, bon nombre de ces prêts n’ont pas de remboursements réguliers ou de dates de remboursement fixes. Essentiellement, vous pouvez emprunter et ne jamais le rembourser.

Cependant, il y a un problème : la valeur de la garantie doit toujours dépasser la limite prédéterminée de la valeur d’emprunt.

Si la valeur de la garantie tombe en dessous de cette limite, le prêt sera liquidé[7] 。 Lors de la liquidation, quelqu’un d’autre rembourse une partie ou la totalité de votre prêt, et il reçoit une partie ou la totalité de votre garantie en retour.

Toutes les demandes d’emprunt qui suivent cette structure financière nécessitent la même construction, qui peut ensuite être organisée de plusieurs façons :

• Trésorerie pour le stockage des garanties des utilisateurs et des actifs empruntés (trésorerie)
• Système de facturation qui suit les garanties et les dettes de chaque utilisateur
• Une fonction qui détermine le taux d’intérêt de l’emprunteur
• Un mécanisme pour vérifier qu’un prêt est correctement garanti, impliquant généralement un oracle de prix externe
• Chemin de liquidation pour l’emprunt lorsque le collatéral est insuffisant
• Un système de gestion des risques qui enregistre le total des emprunts et d’autres indicateurs de sécurité, tels que les limites d’emprunt globales et par utilisateur, les garanties minimales et les ratios de surcollatéralisation spécifiques
• Interface permettant aux utilisateurs d’ajouter et de supprimer des garanties, d’emprunter et de rembourser des objectifs

! [Interprétation approfondie de l’évolution de l’architecture des applications de prêt sur Ethereum] (https://cdn-img.panewslab.com//panews/2022/10/15/images/f004f36e16730c2be0735220dc98b6f8.png) Le processus de prêt dans MakerDAO, toutes les ressources de l’application utilisent les mêmes étapes et fonctions

L’emprunt et le prêt peuvent être considérés comme des fonctions distinctes. Dans la DeFi, nous trouvons les deux fonctionnalités dans la plupart des applications de prêt, mais elles ne s’intègrent pas toujours bien. Chez Compound, Aave et Euler, les taux d’intérêt pour les emprunteurs et les prêteurs sont corrélés en interne ; En fait, c’est ce qui permet à ces applications de fonctionner avec un minimum d’intervention.

D’autre part, MakerDAO et Yield prêtent aux emprunteurs leurs actifs à partir d’eux-mêmes (le protocole lui-même).

Ils ne demandent pas aux utilisateurs de fournir des actifs pour que d’autres utilisateurs puissent les emprunter.

Cet article se concentrera sur l’emprunt et ignorera largement les prêts. L’emprunt est beaucoup plus complexe en raison des exigences hypothécaires, et la compréhension des habitudes d’emprunt permet souvent de mieux comprendre l’ensemble de l’accord.

Évolution architecturale de MakerDAO

! [Interprétation approfondie de l’évolution de l’architecture des applications de prêt sur Ethereum] (https://cdn-img.panewslab.com//panews/2022/10/15/images/42e228c9d77f99385bb5d49f98064ed0.png)

MakerDAO (en anglais seulement)[8] [9], lancé en novembre 2019 , qui détient 4,95 milliards de dollars en garanties. Bien que son architecture modulaire comporte des contrats différents et une terminologie unique pour chaque fonction, elle reste facile à comprendre et à vérifier.

La fonctionnalité de trésorerie de MakerDAO est représentée par des contrats de jointure[10] Gérer.

Chaque jeton approuvé en tant que garantie fait l’objet d’un contrat distinct[11] 。

MakerDAO ne possède pas d’actifs empruntés DAI. Il est simplement frappé et détruit au besoin[12] Allez.

Facturation dans les contrats vat.sol[13] [14]Traitement interne. Join met à jour ce contrat lorsque la garantie entre ou sort du système [15]。 Si un utilisateur emprunte, il contracte directement avec vat.sol Interagir.

Cette action met à jour le solde de la dette de l’utilisateur et lui permet de frapper du DAI en DAI.

Pour rembourser, les utilisateurs brûlent des DAI dans le contrat DAI Join. Ce processus met ensuite à jour la TVA pour permettre à l’utilisateur de régler le prêt.

De plus, le contrat vat.sol agit en tant que gestionnaire de risques[16] Moteur. Il maintient des limites d’emprunt complètes, fixe des seuils minimaux par utilisateur et supervise les ratios de garantie. Lorsque le solde de la dette ou de la garantie d’un utilisateur change, le contrat vat.sol évalue les taux d’intérêt et les taux au comptant.

Il s’agit des taux d’intérêt basés sur la garantie utilisée et le rapport DAI / prix de la garantie en vigueur. Il est intéressant de noter que ces valeurs sont saisies dans le contrat vat.sol par d’autres contrats MakerDAO, ce qui est différent de la plupart des autres applications.

MakerDAO a donné la priorité à la sécurité dès la phase de conception : des facteurs tels que les coûts de l’essence étaient secondaires, l’expérience utilisateur était secondaire et la concurrence était négligeable.

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

Cependant, ses vastes actifs sous gestion et ses antécédents d’opérations sans violations majeures mettent en évidence sa conception et son exécution robustes.

Faits saillants de MakerDAO :

Chaque actif a son propre contrat.

La fonction de facturation est centralisée dans un contrat unique, qui enregistre et exécute également les paramètres de risque, y compris les contrôles de garantie

Contrairement à d’autres applications, les oracles viennent renouveler des contrats et superviser des hypothèques

Les oracles des prix et des taux d’intérêt utilisent des interfaces différentes

Les taux d’intérêt proviennent de l’extérieur

Pour emprunter, les utilisateurs doivent interagir avec plusieurs contrats

Evolution architecturale du protocole Yield

! [Interprétation approfondie de l’évolution de l’architecture des applications de prêt sur Ethereum] (https://cdn-img.panewslab.com//panews/2022/10/15/images/c24841105c321d8451af0d0a7534fa24.png)

Rendement v1[17] [18] Comme l’utilisation de YieldSpace Preuve de concept pour un taux d’intérêt fixe. Cette version construit son moteur d’endettement hypothécaire sur MakerDAO. Cependant, Yield v1 est coûteux à utiliser et difficile à améliorer avec de nouvelles fonctionnalités.

Reconnaissant le potentiel de YieldSpace, nous sommes rapidement passés à Yield v2[19] [20]。 Yield v2 s’inspire toujours de MakerDAO, mais est désormais entièrement indépendant, lancé en octobre 2021 ； Yield v2 donne la priorité à la réduction des coûts de gaz et à l’amélioration de l’expérience utilisateur.

! [Interprétation approfondie de l’évolution de l’architecture des applications de prêt sur Ethereum] (https://cdn-img.panewslab.com//panews/2022/10/15/images/60d6467c33d1a63479bea607edbc7419.png) Le processus d’emprunt dans Yield v2 est fortement influencé par MakerDAO

L’ensemble de la facturation, de la gestion des risques et des vérifications hypothécaires sont regroupés en un seul contrat : Cauldron[21] [22]。 Suivant l’approche de MakerDAO, la fonctionnalité de coffre-fort est distribuée dans le contrat de jointure , chaque contrat est dédié à un actif spécifique.

Amélioration de l’intégration des oracles, combinant les oracles des prix et des taux d’intérêt dans une interface commune[23] [24]。 Nous avons inversé le flux d’oracle de MakerDAO pour Cauldron Consultez l’oracle au besoin pour la vérification de l’hypothèque. Pour autant que je sache, c’est le processus préféré pour toutes les autres applications, à l’exception de MakerDAO.

Une autre différence significative par rapport à l’approche MakerDAO est l’introduction de Ladle[25] 。 Le contrat est le seul intermédiaire entre l’utilisateur et Yield. Il dispose d’un contrôle étendu sur les coffres-forts et les factures, et à son tour, il offre une énorme flexibilité pour le développement de fonctionnalités.

Pour résumer, le prêt dans Yield v2 fonctionne comme suit :

• Chaque ressource dispose de son propre contrat de coffre-fort dédié.
• Le contrat unique centralise les fonctions de facturation. Le contrat supervise également les mesures de gestion des risques et effectue des inspections hypothécaires.
• La fonction hypothécaire consulte l’oracle pour déterminer le prix et le 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 de l’extérieur.
• Les utilisateurs peuvent emprunter en émettant une seule transaction à un contrat.

L’évolution architecturale du complexe

! [Interprétation approfondie de l’évolution de l’architecture des applications de prêt sur Ethereum] (https://cdn-img.panewslab.com//panews/2022/10/15/images/096aad229c90d42d135342e29de817a8.png)

La première version de Compound[26] [27]est une preuve de concept [28], indiquant qu’un marché des devises peut être établi sur Ethereum. Par conséquent, sa conception privilégie la simplicité. MoneyMarket.sol (en anglais seulement) Le contrat englobe toutes les fonctions, y compris l’emprunt.

! [Interprétation approfondie de l’évolution de l’architecture des applications de prêt sur Ethereum] (https://cdn-img.panewslab.com//panews/2022/10/15/images/5c09a9eb804376aec085f6af1c3f9e2e.png) Le processus d’emprunt dans Compound v1 est simple et efficace

Les tâches de coffre-fort, de facturation et de gestion des risques, telles que les vérifications hypothécaires, sont regroupées en un seul contrat.

Le contrat récupère le prix auprès de l’oracle, mais détermine le taux d’intérêt en fonction de l’utilisation de l’actif.

L’utilisateur n’interagit qu’avec le contrat, bien qu’il doive être appelé séparément pour fournir des garanties et emprunter des actifs.

Composé v2

Composé v2[29] Lancé en mai 2019, il a déclenché l’ère du yield farming et inspiré d’innombrables fourchettes. Il agit également comme un marché monétaire, permettant aux utilisateurs de déposer et d’emprunter des actifs.

D’après son livre blanc[30] et la structure, il est clair que l’objectif principal de Compound v2 est de représenter les positions de prêt en utilisant la norme ERC20. Cela garantit la composabilité, permettant aux utilisateurs de prêter à Compound, puis d’utiliser ces positions portant intérêt dans d’autres applications blockchain.

Il est intéressant de noter que le livre blanc ne met pas l’accent sur le fait que Compound v2 sera récompensé[31] Incorporé dans ses contrats intelligents. En raison de cette omission, l’impact énorme de la fonctionnalité peut ne pas être prévu.

! [Interprétation approfondie de l’évolution de l’architecture des applications de prêt sur Ethereum] (https://cdn-img.panewslab.com//panews/2022/10/15/images/f2698573a47c696f279f9d32beefcf9f.png) Le processus d’emprunt dans Compound v2, qui tokenise pour la première fois les positions de prêt

Chaque actif a son propre contrat de financement.

La fonction de facturation est également séparée, et chaque cToken enregistre les garanties et les dettes de l’utilisateur.

Le contrôleur enregistre et exécute les paramètres de gestion des risques, y compris les vérifications des garanties.

Le contrôleur est responsable de la garantie de l’oracle du prix de référence du contrat et du taux d’intérêt de cToken.

Les oracles des prix et des taux d’intérêt fonctionnent via différentes interfaces.

Le taux d’intérêt est dérivé du taux d’utilisation interne de l’actif.

Les utilisateurs doivent interagir avec plusieurs contrats pour emprunter.

Composé v3

Composé v3[32] [33] Sortie en 2022 [34], en adoptant une stratégie de gestion des risques plus prudente, en séparant les liquidités dans un pool de chaque actif empruntable. Milieu. La conception met également l’accent sur la convivialité et le coût de l’essence.

! [Interprétation approfondie de l’évolution de l’architecture des applications de prêt sur Ethereum] (https://cdn-img.panewslab.com//panews/2022/10/15/images/4e2a64278626d39b41f2ab86baddb126.png) Le processus d’emprunt dans Compound v3 (Comet). Retour à l’essentiel, retour à la sécurité. Cependant, avec une meilleure expérience utilisateur.

Avec moins d’appels nécessaires, le système est plus intuitif pour les développeurs et les utilisateurs. De plus, la conception à contrat unique réduit les coûts de gaz en minimisant les appels entre les contrats. Les marchés de devises isolés sont une défense contre les attaques basées sur les oracles, ce qui est actuellement un problème de sécurité majeur.

Parmi les autres fonctionnalités pertinentes mentionnées dans l’article, citons (mentionnées dans les notes de version) :

Refonte des moteurs de gestion des risques et de compensation. Cette conception améliore la sécurité des fonds tout en étant plus conviviale pour les emprunteurs.

Imposer des restrictions sur les actifs hypothécaires personnels sur l’ensemble du marché afin de réduire les risques.

Les modèles de taux d’intérêt pour le revenu et l’emprunt sont désormais séparés, et la gouvernance a un contrôle total sur la politique économique.

Il est intéressant de noter que Compound v3 reflète l’architecture de Compound v1, permettant à un seul contrat de gérer toutes les fonctions de chaque actif empruntable. Parmi les autres caractéristiques notables, citons :

Seuls les actifs empruntés peuvent être empruntés, et les actifs garantis ne peuvent pas être empruntés.

Dans Compound v3, le collatéral ne génère pas de rendement.

L’interdiction d’emprunter des biens grevés accroît la sécurité de la personne qui les a déposés. Cela réduit la probabilité d’erreurs de gouvernance ou d’attaques intentionnelles compromettant les garanties.

La suppression des rendements de l’offre de garantie peut être le résultat de la parution de Compound à accumuler beaucoup de liquidités dans la v2. Mon intuition est que dans Compound v2, la limite d’emprunt est inférieure ou pas supérieure à l’actif que l’utilisateur prête à l’application.

En supposant qu’ils gèrent un niveau de liquidité similaire pour la v3, l’interdiction de prêter des garanties peut sécuriser l’application, ce qui est l’un des principaux objectifs de la v3.

D’un point de vue architectural :

Chaque marché des devises est un contrat distinct contenant des coffres-forts, des factures et la gestion des risques

Chaque marché des devises conserve l’actif empruntable et tous ses jetons d’actifs collatéralisés approuvés, ce qui permet de répartir les actifs dans l’ensemble de l’application

Le prix de l’alimentation est le seul intrant externe ; Les taux d’emprunt sont générés à l’interne

Les fonctions traditionnelles telles que l’approvisionnement/le retrait/l’emprunt/le remboursement sont intelligemment intégrées. Aujourd’hui, retirer des actifs empruntables du marché monétaire signifie emprunter, tandis que fournir des actifs empruntables signifie rembourser des dettes ou des prêts en fonction des utilisateurs

Les contrats de routage intégrés permettent d’effectuer plusieurs opérations en un seul appel

L’évolution architecturale d’Aave

! [Interprétation approfondie de l’évolution de l’architecture des applications de prêt sur Ethereum] (https://cdn-img.panewslab.com//panews/2022/10/15/images/eefde1e6fa9d58e65f3d146ae9649d2c.png)

Fantôme v1[35] [36] Lancé en octobre 2019 pour remplacer ETHLend. Aave v1 introduit un pool de liquidité partagé au lieu de l’approche peer-to-peer d’ETHLend.

! [Interprétation approfondie de l’évolution de l’architecture des applications de prêt sur Ethereum] (https://cdn-img.panewslab.com//panews/2022/10/15/images/e865cd30bcad20378b0c82ccbb538b98.png) Le processus d’emprunt dans Aave v1, qui rassemble l’efficacité du calcul de la soumission de liquidité

Comme dans Yield v2, routage des contrats[37] [38]Contrôlez la logique métier. LendingPoolCore (en anglais seulement) Permet la facturation, la gestion des risques et les fonctions de coffre-fort. La centralisation des coffres-forts dans un seul contrat est un point de différence par rapport à Compound v2.

Conservez le chèque hypothécaire dans votre propre contrat[39] , invoquée à partir d’un routeur plutôt que d’un contrat comptable, cette décision peut sembler faible, mais comme la version v2 d’Aave est sortie deux ans après la version v1, elle a très probablement servi l’objectif.

Le contrat LendingPoolCore gère les coffres-forts et les factures

LendingPoolDataProvider gère la vérification des prêts hypothécaires et interagit avec les oracles

LendingPool agit comme un point d’entrée de l’utilisateur et met en œuvre la logique métier

Le taux d’emprunt est déterminé en interne et ne repose que sur la rétroaction des prix

Fantôme v2

Fantôme v2[40] [41] Sortie en décembre 2021 [42]。 Bien qu’il conserve des fonctionnalités similaires à celles d’Aave v1, il introduit une architecture améliorée et plus simple par rapport à Aave v1 et Compound v2. Dans cette version, Aave a également introduit aToken [43](similaire au cToken de Compound) et vToken , qui signifie dette tokenisée.

! [Interprétation approfondie de l’évolution de l’architecture des applications de prêt sur Ethereum] (https://cdn-img.panewslab.com//panews/2022/10/15/images/c8ccb2478d59ac6e13a859b6bffdba0f.png) Aave v2 a une architecture très propre et est entièrement tokenisé

Pour simplifier, certaines fonctionnalités utilisées en utilisation limitée dans Aave v1 ont été omises. Les problèmes d’Aave v1, tels que les représentations complexes des intérêts courus, ont été résolus dans Aave v2.

Le contrat LendingPool intègre des fonctionnalités de facturation globale et de gestion des risques telles que la vérification des prêts hypothécaires. Il sert de point d’accès principal pour les utilisateurs

Les tokens représentent des garanties, similaires aux positions de prêt. La garantie de l’utilisateur est représentée par l’aToken qu’il détient, et la fonction de coffre-fort est distribuée sur tous les aTokens

vToken est utilisé pour représenter les positions de dette. La dette d’un utilisateur est représentée par le vToken qu’il détient

Fantôme v3

Fantôme v3[44] [45] Sortie en janvier 2023 , avec prise en charge multi-chaînes et d’autres fonctionnalités. L’ajout de ceux-ci ne modifie pas l’architecture de base. Cette mise à jour comprend également une amélioration de la gestion des risques et de l’efficacité du gaz.

Malgré de nombreuses avancées, Aave v3 n’est pas fondamentalement différent d’Aave v2 pour les besoins de cette étude. En fait, cela peut indiquer que l’architecture d’Aave v2 reste robuste en 2023.

L’évolution de l’architecture d’Euler ! [Interprétation approfondie de l’évolution de l’architecture des applications de prêt sur Ethereum] (https://cdn-img.panewslab.com//panews/2022/10/15/images/f7c7040faaf0dad6b78bdd00d2f50aff.png)

Euler[46] [47] Lancé en décembre 2022 , conçu pour fournir des fonctionnalités sans autorisation et une gouvernance minimale pour le marché des devises.

L’une des caractéristiques de son design est le diamant[48] [49]comme le mode. Un seul contrat possède tout l’espace de stockage d’une application [50]。 La boutique est accessible via différents proxys Accès aux différents éléments conceptuels de chaque système de gestion des agents.

! [Interprétation approfondie de l’évolution de l’architecture des applications de prêt sur Ethereum] (https://cdn-img.panewslab.com//panews/2022/10/15/images/a23e03b0b8e9c74b6d36985e3a95b3fb.png) Euler

Bien qu’un contrat stocke tous les actifs, les factures et les données de gestion des risques, il existe toujours des eTokens pour les garanties et les emprunts, et des dTokens pour les dettes, similaires à Aave v2. Cependant, ces contrats de jetons ne sont qu’une vue du contrat de stockage central.

Contrat de stockage[51] Gérez les variables de facturation.

Contrats BaseLogic[52] Agir comme un coffre-fort.

Contrat RiskManager[53] Superviser les variables et les fonctions de gestion des risques, y compris les vérifications hypothécaires.

L’analyse du code montre que le coût minimal du gaz est une priorité, ce qui permet à la conception globale d’éliminer le besoin d’appels intercontractuels. La sécurité est assurée par des tests et des audits rigoureux. Seule la logique est distribuée dans les modules, et en tant qu’implémentation du contrat de stockage, le contrat de stockage agit principalement comme un contrat proxy.

Cette conception uniforme permet également des mises à niveau faciles. Si vous n’avez pas besoin de modifier le stockage, vous pouvez rapidement remplacer les modules pour modifier ou introduire des fonctionnalités.

Euler a été piraté 15 mois après sa sortie et 6 mois après que la mise à jour ait introduit une vulnérabilité exploitée.

Je ne pense pas qu’il s’agisse de la perte d’actifs due à son architecture globale ; À l’inverse, la surveillance des mises à jour de code est insuffisante.

En conclusion

Les premières applications d’Ethereum telles que MakerDAO, Compound et Aave ont démontré le potentiel des prêts surcollatéralisés d’Ethereum. Une fois que ces preuves de concept se sont avérées fructueuses, l’accent a été mis sur l’introduction d’une gamme de nouvelles fonctionnalités pour gagner des parts de marché. Les versions ultérieures de Compound et d’Aave ont introduit l’agriculture de rendement, la composabilité et la liquidité collective, des techniques qui ont prospéré en particulier dans des conditions de marché haussier.

Un développement important est l’introduction de positions de prêt tokenisées dans Compound v2, ce qui permet à ces positions d’être reconnues comme des actifs standard par d’autres applications. 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.

Les coûts élevés du gaz sont devenus un problème majeur pendant les marchés haussiers, ce qui a entraîné des changements dans l’expérience utilisateur, comme l’ont fait Yield v2, Aave v2 et Euler. Les contrats de routeur et leur mise en œuvre dans leur ensemble permettent de réduire les coûts de transaction pour les utilisateurs. Cependant, cela se fait au prix d’un code plus complexe et donc plus risqué.

Compound 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, pourrait avoir un impact sur la conception des demandes de prêt hypothécaire à l’avenir.

Dans cet article, je donne un aperçu complet des principales applications d’emprunt de garanties sur Ethereum. Les méthodes que j’utilise pour analyser chaque demande peuvent également être utilisées pour saisir rapidement la complexité d’autres demandes de prêt hypothécaire.

Lorsque vous développez des applications de prêt blockchain, tenez toujours compte du stockage des actifs, du placement des enregistrements de facturation et des méthodes d’évaluation des risques et des garanties. Lorsque vous tenez compte de ces considérations, utilisez les modifications historiques appliquées précédemment et les informations de cette vue d’ensemble pour éclairer vos décisions.