Apportez la diversité des dépendances à DeFi au lieu de vous fier à un seul oracle. Les primitives DeFi ne doivent avoir aucune gouvernance, aucune évolutivité, aucun oracles ou dépendances externes de quelque nature que ce soit.
arrière-plan
J'aime DeFi. Les protocoles de paiement sans autorisation et un système financier ouvert sont ce qui m'a d'abord attiré vers Bitcoin, puis vers le monde plus large des crypto-monnaies.
En 2018, j'ai lu sur Uniswap, ce qui m'a ouvert les yeux sur le pouvoir du changement qui se produisait dans le monde de la cryptographie. Ce segment s'appellera DeFi (même si j'aime toujours Open Finance).
Mais après des années de piratages répétés et de milliards de dollars volés, même les croyants les plus ardents ont des raisons de se demander si DeFi conviendra un jour à une utilisation grand public, et encore moins deviendra un élément central du système financier mondial.
La réponse est : ce ne sera pas... du moins pas de la façon dont il est actuellement configuré.
Chez Nascent, nous avons beaucoup investi dans la sécurité. En 2020, nous avons été le premier investisseur à confier à nos sociétés de portefeuille un cabinet d'audit de niveau 1 (Open Zeppelin) pour garantir un accès prioritaire à des examens de sécurité rigoureux avant le lancement. Nous sommes également les premiers partisans de Spearbit, Code4rena, Macro et Skylock.
Nous consacrons également notre temps à créer des outils pour l'industrie. Le Simple Security Toolkit a été forké près de 100 fois, et nous avons récemment annoncé la version bêta de Pyrometer, un outil open source pour les auditeurs et les développeurs qui intègre l'exécution symbolique, l'interprétation abstraite et l'analyse statique.
Grâce à ces efforts, nous croyons qu'être en sécurité n'est pas seulement une question de « faire plus d'efforts ». C'est nécessaire, mais pas suffisant - dans l'ensemble de l'industrie, la fréquence et la gravité des vulnérabilités sont au moins deux ordres de grandeur plus élevées que les niveaux acceptables pour une adoption généralisée.
En 2022, plus de 3,8 milliards de dollars ont été volés par des attaques de piratage, exploitant principalement les vulnérabilités des protocoles DeFi et des ponts inter-chaînes. Alors que certaines vulnérabilités sont le résultat d'attitudes de sécurité inquiétantes, même les protocoles développés par des équipes respectées et suivant les meilleurs processus actuels ne sont pas à l'abri.
** Si nous voulons voir des milliards de personnes compter sur DeFi, nous devons repenser fondamentalement la conception et la sécurité des protocoles. **
Chez Nascent, nous pensons qu'il existe une gamme de concepts liés à la sécurité qui méritent une exploration et une exploration plus approfondies.
Aujourd'hui, nous commencerons par expliquer le concept d'un "protocole sans oracle" et pourquoi nous pensons qu'il indiquera fondamentalement une architecture plus robuste et sécurisée pour DeFi.
Protocoles modulaires et primitives
De nombreux protocoles DeFi aiment se déguiser en "primitifs", espérant que d'autres équipes pourront créer des produits ou des protocoles composables basés sur eux.
Je voudrais proposer une nouvelle définition : Pour être qualifié de primitif, un contrat ne doit avoir aucune dépendance externe autre que la blockchain sur laquelle il est déployé.
Cela signifie pas de gouvernance, pas d'évolutivité, pas d'oracles.
Une fois qu'une dépendance externe est introduite dans un contrat, le contrat hérite de tout risque associé à cette dépendance. La gouvernance de la fonctionnalité du contrat implique une certaine forme d'évolutivité, nécessitant un modèle de menace qui prend en compte à la fois l'éventail des changements possibles et les conditions actuelles et futures probables. De même, les oracles introduisent des données externes et toutes les dépendances qui leur sont associées pour fournir ces données, y compris tous les changements potentiels dans leur exactitude et leur actualité.
Une primitive doit simplement faire ce qu'elle dit sur le pot - c'est-à-dire ni plus ni moins, sans ajouter de dépendances.
Aujourd'hui, il existe étonnamment peu de protocoles DeFi qui correspondent à cette définition de base. Uniswap v1 est probablement le plus connu, mais même Uniswap v2 et v3 (bien que dans l'esprit de cette définition du point de vue de la sécurité) ne sont pas éligibles car ils permettent la gestion de certaines fonctionnalités telles que la conversion des frais de protocole et le financement La possibilité pour les pools d'introduire nouveaux niveaux de frais.
Cependant, cette fonctionnalité de gouvernance limitée ne signifie pas le risque d'introduire des proxies massivement évolutifs qui existent dans de nombreux autres protocoles, et Uniswap est le grand gagnant ici :
pas d'oracle
entièrement en chaîne
** Uniswap a connu un grand succès dans l'ensemble, et nous devrions tous être reconnaissants de son émergence en tant qu'échange décentralisé grand public et des nouvelles expériences DEX qu'il a inspirées. Son ascension a été largement attribuée à la fourniture de liquidités à tous les prix et à la simplicité d'apprendre à devenir un teneur de marché, Uniswap remplaçant finalement les projets antérieurs qui étaient plus centralisés ou reposaient sur des schémas de jetons douteux. **
Au fur et à mesure que l'industrie évoluait, Uniswap a lancé une nouvelle version de son protocole, déplaçant l'espace de conception pour qu'il ressemble davantage à un carnet de commandes. Uniswap v3 introduit le concept de positions de liquidité non homogènes, où les fournisseurs de liquidité (LP) ont la possibilité de regrouper leur liquidité dans une fourchette spécifique. Cela permet aux LPs de capter une plus grande part des frais de conversion des transactions dans cette fourchette, mais augmente également leurs pertes de divergence lorsque les prix changent. Cela a conduit à une utilisation plus efficace du capital et à la professionnalisation des LP sur le marché, ainsi qu'à l'émergence d'un écosystème d'outils de gestion des positions, notamment Arrakis, Gamma et Sommelier.
Je m'attends à ce stade à ce que de nombreux lecteurs pensent "eh bien, aucun oracle n'est bon pour un DEX, mais qu'en est-il d'un protocole de prêt ? Vous avez besoin d'un oracle pour le prêt !"
Je suis d'accord : le prêt nécessite des oracles... mais, comme pour les DEX, ils peuvent être déplacés en dehors du protocole.
Restructurer les prêts
Récemment, nous avons remarqué un vif intérêt des investisseurs pour les nouveaux protocoles de prêt sans oracle tels que Ajna, Ethereum Credit Guild, Metastreet’s Automated Tranche Maker et Blur/Paradigm’s Blend.
Contrairement aux marchés de prêt DeFi traditionnels, Gauntlet n'a pas de facteur de garantie défini par un organe de gouvernance, ni d'oracle universel unique comme Chainlink qui fournit des prix d'actifs "réels" pour tous les utilisateurs et fonctions de protocole. Au lieu de cela, les prêteurs sont chargés d'évaluer les risques, de décider du montant de la garantie qu'ils veulent des emprunteurs et doivent mettre à jour leurs critères de prêt à mesure que les prix des actifs changent.
En règle générale, le prêteur choisit l'actif spécifique qu'il acceptera en garantie (par exemple, les jetons BAYC, un Bored Ape NFT, etc.), l'actif qu'il propose d'emprunter (par exemple, USDC) et l'ensemble Déterminer le ratio de l'emprunteur liquidé actifs de cotation en actifs collatéraux. Les emprunteurs peuvent alors soumettre des garanties et emprunter l'actif coté aux taux du marché en vigueur.
Notez qu'aucun oracle n'est requis puisque l'emprunteur et le prêteur ont convenu d'un prêt où la liquidation est déterminée via un ratio basé sur le nombre d'unités garanties sur chaque actif plutôt que de s'appuyer sur les prix en dollars. Cependant, si la valeur relative en dollars de l'un ou l'autre des actifs change, les prêteurs peuvent souhaiter ajuster les conditions de prêt actuelles ou futures pour refléter ce qu'ils considèrent comme un ratio de garantie sûr.
Avantage clé de cette approche : il est pratiquement impossible qu'un protocole fasse faillite. Étant donné que chaque prêteur individuel est responsable en dernier ressort de la solvabilité de son propre prêt, il n'y a pas de concept de "créance irrécouvrable" qui doit être socialisé par les trésoreries du DAO, les fonds d'assurance ou parmi les emprunteurs. **
Est-il sûr pour quelqu'un d'hypothéquer son ETH pour emprunter USDC à 95% du montant du prêt ? Cela n'a pas d'importance.
Vous vous sentez mal à l'aise de contracter un prêt avec une garantie MKR, mais vous n'avez qu'un taux de garantie de prêt de 10 % ? Cela n'a pas d'importance.
Blur's Blend suppose "l'existence de prêteurs plus sophistiqués qui peuvent participer à des accords complexes en chaîne et hors chaîne, évaluer les risques et utiliser leur propre capital". Cela a du sens dans le contexte où Blur est le lieu principal pour les traders professionnels de NFT, mais pour l'utilisateur moyen, cela semble être beaucoup plus de travail que de contracter un prêt sur Aave ou Compound.
La bonne nouvelle, c'est qu'il n'est pas nécessaire qu'il en soit ainsi.
D'autres protocoles ou services peuvent vous permettre de maintenir facilement une exigence de taux de garantie cohérente même si le prix de la garantie que vous prêtez fluctue. En prenant Ajna comme exemple, il sera possible d'utiliser Oasis et DeFi Saver (ou d'autres protocoles/services) pour ajuster automatiquement les ticks que vous fournissez. Vous pouvez même créer un coffre-fort qui permet aux utilisateurs de fournir DAI ou USDC, et d'emprunter le même actif avec le même facteur de garantie qu'Aave, en rééquilibrant automatiquement entre les pools de fonds pour maximiser le taux de prêt. Un tel coffre-fort pourrait même utiliser Chainlink comme oracle, rendant l'expérience utilisateur et le profil de risque pour les prêteurs presque identiques à ce qu'ils sont aujourd'hui avec Aave.
Mais pourquoi créer un protocole au-dessus d'un protocole sans oracle comme Ajna, ou un protocole original, s'il s'agit simplement de superposer un protocole ou un service pour reproduire l'expérience utilisateur et les risques existants d'Aave ?
Un marché unifié sécurisé par la diversité
Soyons clairs : ** Les vraies institutions financières ne mettront jamais (et ne devraient pas) investir des milliards de dollars dans un protocole dont la sécurité dépend uniquement de Chainlink. **
La mise en ligne fiable de données hors chaîne implique de nombreux problèmes complexes, en particulier la nécessité de fonctionner de manière décentralisée et résistante à la censure. Bien que Chainlink fasse un travail admirable dans ces contraintes, elles deviennent également un point de défaillance unique potentiel pour l'ensemble de DeFi.
Pas de protocoles d'oracle - en fait, les protocoles explicitement conçus pour permettre aux utilisateurs d'apporter leurs propres oracles (BYOO : Apportez votre propre oracle), offrent une voie alternative, en particulier pour ceux qui n'ont pas besoin d'être décentralisés ou résistants à la censure. leurs propres sources de données de haute qualité.
Il est tout à fait possible que la plupart des utilisateurs d'un protocole sans oracle comme Ajna s'appuient toujours sur un protocole oracle public comme Chainlink, via un outil comme Oasis pour aider à gérer en toute sécurité leurs positions de prêt. Mais ils pourront également fonctionner de manière transparente sur le même marché avec des utilisateurs sophistiqués qui décident de s'appuyer sur un autre protocole (comme Pyth), divers oracles basés sur zk, des API Bloomberg ou même leurs propres calculs de prix internes.
Comme nous l'avons vu récemment dans Ethereum lui-même, la capacité de s'appuyer sur une saine diversité de clients permet d'éviter les temps d'arrêt. Une approche en couches du développement de protocoles, permettant une diversité de fournisseurs de services critiques pour la sécurité, a le potentiel d'apporter une forme similaire de robustesse dans DeFi, où les problèmes peuvent être isolés et n'affecter qu'un sous-ensemble d'utilisateurs.
En ce qui concerne Ajna, rappelez-vous qu'il ne s'agit pas seulement d'un protocole sans oracle, c'est un protocole primitif : il n'a aucune gouvernance, aucune évolutivité, aucun oracle ou dépendance externe d'aucune sorte. Cela signifie que les emprunteurs et les prêteurs peuvent chacun formuler leurs propres exigences, choisir leurs propres accords de gestion et prestataires de services, chacun avec ses propres dépendances en matière de résultats. Certains utilisateurs peuvent choisir d'utiliser des services qui reposent sur Chainlink et reflètent les actifs et les ratios de garantie d'Aave, tandis que d'autres peuvent choisir d'utiliser l'API de Bloomberg et ne prêter contre ETH qu'avec des ratios de garantie conservateurs.
Si un événement se produit qui endommage un oracle ou brise rapidement la valeur d'un actif garanti, les utilisateurs qui utilisent un oracle différent ou qui n'ont aucun prêt sur cet actif ne seront absolument pas affectés.
Et, quels que soient ces choix, les utilisateurs mettront toujours en commun leurs liquidités et interagiront avec des contreparties sur un seul marché unifié via Ajna. C'est le travail des vrais primitifs DeFi : fournir un marché efficace et sécurisé où les parties peuvent se trouver et régler des transactions, en cours d'exécution pour toujours.
Si vous vous demandez à quel point vous pouvez construire sur des primitives de type protocole : Infinity Pools est un futur échange décentralisé construit sur Uniswap V3, capable d'un effet de levier pratiquement illimité sur n'importe quel actif, sans liquidations, sans risque de contrepartie, et pas d'oracles.
L'avenir de DeFi est en couches
Est-ce une bonne idée de faire la transition de DeFi pour qu'il soit principalement construit sur des primitives immuables ? Après tout, nous avons construit des centaines de milliards d'échanges et de prêts à partir de zéro, en nous basant sur la flexibilité et la facilité d'utilisation que permettent la gouvernance, l'évolutivité et les oracles.
Je pense que c'est nécessaire.
** La gouvernance, l'évolutivité et les oracles ne sont pas intrinsèquement mauvais. Au contraire, ils sont très utiles dans un large éventail d'environnements. Cependant, ils augmentent la surface d'attaque du protocole et entraînent des vulnérabilités et des attaques pour la plupart ou tous les utilisateurs du protocole en raison de l'activation de ces fonctionnalités. **
Le déplacement d'autant de logique et de dépendances que possible hors des primitives de niveau le plus bas crée un marché plus robuste pour les services de niveau supérieur, tout en unifiant la liquidité par le biais de contrats avec la surface d'attaque minimale absolue.
Les primitives elles-mêmes peuvent parfois devoir être remplacées, peut-être en raison d'importantes améliorations fonctionnelles ou d'efficacité apportées par les conceptions futures, ou parce que des bogues potentiels sont découverts. La bonne nouvelle ici est que si quelqu'un développe une meilleure façon de faire une primitive, la plupart des protocoles et fournisseurs de services ci-dessus pourront migrer leurs utilisateurs vers la nouvelle primitive améliorée car le niveau supérieur Le service a été explicitement conçu pour être modulaire.
Encore une fois, est-ce que ça vaut le coup ?
Je pense que oui.
La blockchain elle-même est très inefficace par rapport à diverses formes de bases de données et de services centralisés. Nous les utilisons parce que nous pensons que la puissance de l'accès sans autorisation et de la composabilité - et la possibilité de choisir de garder notre propre richesse pour nous-mêmes ou de choisir un fournisseur de services en qui nous avons confiance - compense largement les défis auxquels nous sommes confrontés en tant qu'utilisateurs. problèmes.
Nous sommes confrontés à un choix similaire lors du choix de la structure de notre protocole DeFi : voulons-nous un protocole qui délègue les décisions sur tous les paramètres utilisateur et les dépendances externes à un petit groupe de délégués qui prennent la peine de participer à la gouvernance ?
Ou choisir celles qui se concentrent sur l'autonomisation des acteurs du marché ? Laisser les utilisateurs prendre leurs propres décisions, ou choisir d'autres protocoles et fournisseurs de services, pour décider en leur propre nom, sans imposer ces décisions à tous ceux avec qui ils souhaitent effectuer des transactions ?
Nous pouvons compter sur un point de défaillance centralisé. Alternativement, nous pouvons choisir d'augmenter la robustesse grâce à la diversité et à la modularité des couches de pile.
Ceux d'entre nous qui travaillent dans cette industrie ont choisi de travailler à la promotion du développement de protocoles décentralisés, sans autorisation et composables, croyant qu'à terme, leurs avantages par rapport aux systèmes traditionnels centralisés et autorisés deviendront indéniables. De même, je pense que les gens finiront par apprécier l'approche modulaire et en couches de la conception du protocole DeFi car elle apporte des améliorations en matière de sécurité et de résilience.
N'oubliez pas : nous ne sommes pas ici pour construire quelque chose de 50 % mieux que ce qui existait avant ; nous devons construire quelque chose de 50 fois mieux.
Que vous croyiez ou non que les conceptions de protocoles sans oracle ou en couches sont l'avenir, j'espère que tout le monde peut convenir que la sécurité dans DeFi n'est pas un problème difficile à résoudre. Si nous n'améliorons jamais la sécurité, le cryptage ne sortira jamais du statut de niche.
En plus des changements de conception de protocole suggérés ci-dessus, il existe une série d'autres mesures concrètes que nous pouvons prendre pour faire avancer les problèmes de sécurité. Restez à l'écoute pour les prochains articles de cette série qui exploreront le potentiel et les défis autour de certains des thèmes.
Voir l'original
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
Pourquoi Defi est cassé sur l'importance des protocoles sans Oracle
Auteur : Dan Elitzer, NASCENT ; Compilateur : Tiny Bear, Denglian Translation Project
Apportez la diversité des dépendances à DeFi au lieu de vous fier à un seul oracle. Les primitives DeFi ne doivent avoir aucune gouvernance, aucune évolutivité, aucun oracles ou dépendances externes de quelque nature que ce soit.
arrière-plan
J'aime DeFi. Les protocoles de paiement sans autorisation et un système financier ouvert sont ce qui m'a d'abord attiré vers Bitcoin, puis vers le monde plus large des crypto-monnaies.
En 2018, j'ai lu sur Uniswap, ce qui m'a ouvert les yeux sur le pouvoir du changement qui se produisait dans le monde de la cryptographie. Ce segment s'appellera DeFi (même si j'aime toujours Open Finance).
Mais après des années de piratages répétés et de milliards de dollars volés, même les croyants les plus ardents ont des raisons de se demander si DeFi conviendra un jour à une utilisation grand public, et encore moins deviendra un élément central du système financier mondial.
La réponse est : ce ne sera pas... du moins pas de la façon dont il est actuellement configuré.
Chez Nascent, nous avons beaucoup investi dans la sécurité. En 2020, nous avons été le premier investisseur à confier à nos sociétés de portefeuille un cabinet d'audit de niveau 1 (Open Zeppelin) pour garantir un accès prioritaire à des examens de sécurité rigoureux avant le lancement. Nous sommes également les premiers partisans de Spearbit, Code4rena, Macro et Skylock.
Nous consacrons également notre temps à créer des outils pour l'industrie. Le Simple Security Toolkit a été forké près de 100 fois, et nous avons récemment annoncé la version bêta de Pyrometer, un outil open source pour les auditeurs et les développeurs qui intègre l'exécution symbolique, l'interprétation abstraite et l'analyse statique.
Grâce à ces efforts, nous croyons qu'être en sécurité n'est pas seulement une question de « faire plus d'efforts ». C'est nécessaire, mais pas suffisant - dans l'ensemble de l'industrie, la fréquence et la gravité des vulnérabilités sont au moins deux ordres de grandeur plus élevées que les niveaux acceptables pour une adoption généralisée.
En 2022, plus de 3,8 milliards de dollars ont été volés par des attaques de piratage, exploitant principalement les vulnérabilités des protocoles DeFi et des ponts inter-chaînes. Alors que certaines vulnérabilités sont le résultat d'attitudes de sécurité inquiétantes, même les protocoles développés par des équipes respectées et suivant les meilleurs processus actuels ne sont pas à l'abri.
** Si nous voulons voir des milliards de personnes compter sur DeFi, nous devons repenser fondamentalement la conception et la sécurité des protocoles. **
Chez Nascent, nous pensons qu'il existe une gamme de concepts liés à la sécurité qui méritent une exploration et une exploration plus approfondies.
Aujourd'hui, nous commencerons par expliquer le concept d'un "protocole sans oracle" et pourquoi nous pensons qu'il indiquera fondamentalement une architecture plus robuste et sécurisée pour DeFi.
Protocoles modulaires et primitives
De nombreux protocoles DeFi aiment se déguiser en "primitifs", espérant que d'autres équipes pourront créer des produits ou des protocoles composables basés sur eux.
Je voudrais proposer une nouvelle définition : Pour être qualifié de primitif, un contrat ne doit avoir aucune dépendance externe autre que la blockchain sur laquelle il est déployé.
Cela signifie pas de gouvernance, pas d'évolutivité, pas d'oracles.
Une fois qu'une dépendance externe est introduite dans un contrat, le contrat hérite de tout risque associé à cette dépendance. La gouvernance de la fonctionnalité du contrat implique une certaine forme d'évolutivité, nécessitant un modèle de menace qui prend en compte à la fois l'éventail des changements possibles et les conditions actuelles et futures probables. De même, les oracles introduisent des données externes et toutes les dépendances qui leur sont associées pour fournir ces données, y compris tous les changements potentiels dans leur exactitude et leur actualité.
Une primitive doit simplement faire ce qu'elle dit sur le pot - c'est-à-dire ni plus ni moins, sans ajouter de dépendances.
Aujourd'hui, il existe étonnamment peu de protocoles DeFi qui correspondent à cette définition de base. Uniswap v1 est probablement le plus connu, mais même Uniswap v2 et v3 (bien que dans l'esprit de cette définition du point de vue de la sécurité) ne sont pas éligibles car ils permettent la gestion de certaines fonctionnalités telles que la conversion des frais de protocole et le financement La possibilité pour les pools d'introduire nouveaux niveaux de frais.
Cependant, cette fonctionnalité de gouvernance limitée ne signifie pas le risque d'introduire des proxies massivement évolutifs qui existent dans de nombreux autres protocoles, et Uniswap est le grand gagnant ici :
** Uniswap a connu un grand succès dans l'ensemble, et nous devrions tous être reconnaissants de son émergence en tant qu'échange décentralisé grand public et des nouvelles expériences DEX qu'il a inspirées. Son ascension a été largement attribuée à la fourniture de liquidités à tous les prix et à la simplicité d'apprendre à devenir un teneur de marché, Uniswap remplaçant finalement les projets antérieurs qui étaient plus centralisés ou reposaient sur des schémas de jetons douteux. **
Au fur et à mesure que l'industrie évoluait, Uniswap a lancé une nouvelle version de son protocole, déplaçant l'espace de conception pour qu'il ressemble davantage à un carnet de commandes. Uniswap v3 introduit le concept de positions de liquidité non homogènes, où les fournisseurs de liquidité (LP) ont la possibilité de regrouper leur liquidité dans une fourchette spécifique. Cela permet aux LPs de capter une plus grande part des frais de conversion des transactions dans cette fourchette, mais augmente également leurs pertes de divergence lorsque les prix changent. Cela a conduit à une utilisation plus efficace du capital et à la professionnalisation des LP sur le marché, ainsi qu'à l'émergence d'un écosystème d'outils de gestion des positions, notamment Arrakis, Gamma et Sommelier.
Je m'attends à ce stade à ce que de nombreux lecteurs pensent "eh bien, aucun oracle n'est bon pour un DEX, mais qu'en est-il d'un protocole de prêt ? Vous avez besoin d'un oracle pour le prêt !"
Je suis d'accord : le prêt nécessite des oracles... mais, comme pour les DEX, ils peuvent être déplacés en dehors du protocole.
Restructurer les prêts
Récemment, nous avons remarqué un vif intérêt des investisseurs pour les nouveaux protocoles de prêt sans oracle tels que Ajna, Ethereum Credit Guild, Metastreet’s Automated Tranche Maker et Blur/Paradigm’s Blend.
Contrairement aux marchés de prêt DeFi traditionnels, Gauntlet n'a pas de facteur de garantie défini par un organe de gouvernance, ni d'oracle universel unique comme Chainlink qui fournit des prix d'actifs "réels" pour tous les utilisateurs et fonctions de protocole. Au lieu de cela, les prêteurs sont chargés d'évaluer les risques, de décider du montant de la garantie qu'ils veulent des emprunteurs et doivent mettre à jour leurs critères de prêt à mesure que les prix des actifs changent.
En règle générale, le prêteur choisit l'actif spécifique qu'il acceptera en garantie (par exemple, les jetons BAYC, un Bored Ape NFT, etc.), l'actif qu'il propose d'emprunter (par exemple, USDC) et l'ensemble Déterminer le ratio de l'emprunteur liquidé actifs de cotation en actifs collatéraux. Les emprunteurs peuvent alors soumettre des garanties et emprunter l'actif coté aux taux du marché en vigueur.
Notez qu'aucun oracle n'est requis puisque l'emprunteur et le prêteur ont convenu d'un prêt où la liquidation est déterminée via un ratio basé sur le nombre d'unités garanties sur chaque actif plutôt que de s'appuyer sur les prix en dollars. Cependant, si la valeur relative en dollars de l'un ou l'autre des actifs change, les prêteurs peuvent souhaiter ajuster les conditions de prêt actuelles ou futures pour refléter ce qu'ils considèrent comme un ratio de garantie sûr.
Avantage clé de cette approche : il est pratiquement impossible qu'un protocole fasse faillite. Étant donné que chaque prêteur individuel est responsable en dernier ressort de la solvabilité de son propre prêt, il n'y a pas de concept de "créance irrécouvrable" qui doit être socialisé par les trésoreries du DAO, les fonds d'assurance ou parmi les emprunteurs. **
Est-il sûr pour quelqu'un d'hypothéquer son ETH pour emprunter USDC à 95% du montant du prêt ? Cela n'a pas d'importance.
Vous vous sentez mal à l'aise de contracter un prêt avec une garantie MKR, mais vous n'avez qu'un taux de garantie de prêt de 10 % ? Cela n'a pas d'importance.
Blur's Blend suppose "l'existence de prêteurs plus sophistiqués qui peuvent participer à des accords complexes en chaîne et hors chaîne, évaluer les risques et utiliser leur propre capital". Cela a du sens dans le contexte où Blur est le lieu principal pour les traders professionnels de NFT, mais pour l'utilisateur moyen, cela semble être beaucoup plus de travail que de contracter un prêt sur Aave ou Compound.
La bonne nouvelle, c'est qu'il n'est pas nécessaire qu'il en soit ainsi.
D'autres protocoles ou services peuvent vous permettre de maintenir facilement une exigence de taux de garantie cohérente même si le prix de la garantie que vous prêtez fluctue. En prenant Ajna comme exemple, il sera possible d'utiliser Oasis et DeFi Saver (ou d'autres protocoles/services) pour ajuster automatiquement les ticks que vous fournissez. Vous pouvez même créer un coffre-fort qui permet aux utilisateurs de fournir DAI ou USDC, et d'emprunter le même actif avec le même facteur de garantie qu'Aave, en rééquilibrant automatiquement entre les pools de fonds pour maximiser le taux de prêt. Un tel coffre-fort pourrait même utiliser Chainlink comme oracle, rendant l'expérience utilisateur et le profil de risque pour les prêteurs presque identiques à ce qu'ils sont aujourd'hui avec Aave.
Mais pourquoi créer un protocole au-dessus d'un protocole sans oracle comme Ajna, ou un protocole original, s'il s'agit simplement de superposer un protocole ou un service pour reproduire l'expérience utilisateur et les risques existants d'Aave ?
Un marché unifié sécurisé par la diversité
Soyons clairs : ** Les vraies institutions financières ne mettront jamais (et ne devraient pas) investir des milliards de dollars dans un protocole dont la sécurité dépend uniquement de Chainlink. **
La mise en ligne fiable de données hors chaîne implique de nombreux problèmes complexes, en particulier la nécessité de fonctionner de manière décentralisée et résistante à la censure. Bien que Chainlink fasse un travail admirable dans ces contraintes, elles deviennent également un point de défaillance unique potentiel pour l'ensemble de DeFi.
Pas de protocoles d'oracle - en fait, les protocoles explicitement conçus pour permettre aux utilisateurs d'apporter leurs propres oracles (BYOO : Apportez votre propre oracle), offrent une voie alternative, en particulier pour ceux qui n'ont pas besoin d'être décentralisés ou résistants à la censure. leurs propres sources de données de haute qualité.
Il est tout à fait possible que la plupart des utilisateurs d'un protocole sans oracle comme Ajna s'appuient toujours sur un protocole oracle public comme Chainlink, via un outil comme Oasis pour aider à gérer en toute sécurité leurs positions de prêt. Mais ils pourront également fonctionner de manière transparente sur le même marché avec des utilisateurs sophistiqués qui décident de s'appuyer sur un autre protocole (comme Pyth), divers oracles basés sur zk, des API Bloomberg ou même leurs propres calculs de prix internes.
Comme nous l'avons vu récemment dans Ethereum lui-même, la capacité de s'appuyer sur une saine diversité de clients permet d'éviter les temps d'arrêt. Une approche en couches du développement de protocoles, permettant une diversité de fournisseurs de services critiques pour la sécurité, a le potentiel d'apporter une forme similaire de robustesse dans DeFi, où les problèmes peuvent être isolés et n'affecter qu'un sous-ensemble d'utilisateurs.
En ce qui concerne Ajna, rappelez-vous qu'il ne s'agit pas seulement d'un protocole sans oracle, c'est un protocole primitif : il n'a aucune gouvernance, aucune évolutivité, aucun oracle ou dépendance externe d'aucune sorte. Cela signifie que les emprunteurs et les prêteurs peuvent chacun formuler leurs propres exigences, choisir leurs propres accords de gestion et prestataires de services, chacun avec ses propres dépendances en matière de résultats. Certains utilisateurs peuvent choisir d'utiliser des services qui reposent sur Chainlink et reflètent les actifs et les ratios de garantie d'Aave, tandis que d'autres peuvent choisir d'utiliser l'API de Bloomberg et ne prêter contre ETH qu'avec des ratios de garantie conservateurs.
Si un événement se produit qui endommage un oracle ou brise rapidement la valeur d'un actif garanti, les utilisateurs qui utilisent un oracle différent ou qui n'ont aucun prêt sur cet actif ne seront absolument pas affectés.
Et, quels que soient ces choix, les utilisateurs mettront toujours en commun leurs liquidités et interagiront avec des contreparties sur un seul marché unifié via Ajna. C'est le travail des vrais primitifs DeFi : fournir un marché efficace et sécurisé où les parties peuvent se trouver et régler des transactions, en cours d'exécution pour toujours.
Si vous vous demandez à quel point vous pouvez construire sur des primitives de type protocole : Infinity Pools est un futur échange décentralisé construit sur Uniswap V3, capable d'un effet de levier pratiquement illimité sur n'importe quel actif, sans liquidations, sans risque de contrepartie, et pas d'oracles.
L'avenir de DeFi est en couches
Est-ce une bonne idée de faire la transition de DeFi pour qu'il soit principalement construit sur des primitives immuables ? Après tout, nous avons construit des centaines de milliards d'échanges et de prêts à partir de zéro, en nous basant sur la flexibilité et la facilité d'utilisation que permettent la gouvernance, l'évolutivité et les oracles.
Je pense que c'est nécessaire.
** La gouvernance, l'évolutivité et les oracles ne sont pas intrinsèquement mauvais. Au contraire, ils sont très utiles dans un large éventail d'environnements. Cependant, ils augmentent la surface d'attaque du protocole et entraînent des vulnérabilités et des attaques pour la plupart ou tous les utilisateurs du protocole en raison de l'activation de ces fonctionnalités. **
Le déplacement d'autant de logique et de dépendances que possible hors des primitives de niveau le plus bas crée un marché plus robuste pour les services de niveau supérieur, tout en unifiant la liquidité par le biais de contrats avec la surface d'attaque minimale absolue.
Les primitives elles-mêmes peuvent parfois devoir être remplacées, peut-être en raison d'importantes améliorations fonctionnelles ou d'efficacité apportées par les conceptions futures, ou parce que des bogues potentiels sont découverts. La bonne nouvelle ici est que si quelqu'un développe une meilleure façon de faire une primitive, la plupart des protocoles et fournisseurs de services ci-dessus pourront migrer leurs utilisateurs vers la nouvelle primitive améliorée car le niveau supérieur Le service a été explicitement conçu pour être modulaire.
Encore une fois, est-ce que ça vaut le coup ?
Je pense que oui.
La blockchain elle-même est très inefficace par rapport à diverses formes de bases de données et de services centralisés. Nous les utilisons parce que nous pensons que la puissance de l'accès sans autorisation et de la composabilité - et la possibilité de choisir de garder notre propre richesse pour nous-mêmes ou de choisir un fournisseur de services en qui nous avons confiance - compense largement les défis auxquels nous sommes confrontés en tant qu'utilisateurs. problèmes.
Nous sommes confrontés à un choix similaire lors du choix de la structure de notre protocole DeFi : voulons-nous un protocole qui délègue les décisions sur tous les paramètres utilisateur et les dépendances externes à un petit groupe de délégués qui prennent la peine de participer à la gouvernance ?
Ou choisir celles qui se concentrent sur l'autonomisation des acteurs du marché ? Laisser les utilisateurs prendre leurs propres décisions, ou choisir d'autres protocoles et fournisseurs de services, pour décider en leur propre nom, sans imposer ces décisions à tous ceux avec qui ils souhaitent effectuer des transactions ?
Nous pouvons compter sur un point de défaillance centralisé. Alternativement, nous pouvons choisir d'augmenter la robustesse grâce à la diversité et à la modularité des couches de pile.
Ceux d'entre nous qui travaillent dans cette industrie ont choisi de travailler à la promotion du développement de protocoles décentralisés, sans autorisation et composables, croyant qu'à terme, leurs avantages par rapport aux systèmes traditionnels centralisés et autorisés deviendront indéniables. De même, je pense que les gens finiront par apprécier l'approche modulaire et en couches de la conception du protocole DeFi car elle apporte des améliorations en matière de sécurité et de résilience.
N'oubliez pas : nous ne sommes pas ici pour construire quelque chose de 50 % mieux que ce qui existait avant ; nous devons construire quelque chose de 50 fois mieux.
Que vous croyiez ou non que les conceptions de protocoles sans oracle ou en couches sont l'avenir, j'espère que tout le monde peut convenir que la sécurité dans DeFi n'est pas un problème difficile à résoudre. Si nous n'améliorons jamais la sécurité, le cryptage ne sortira jamais du statut de niche.
En plus des changements de conception de protocole suggérés ci-dessus, il existe une série d'autres mesures concrètes que nous pouvons prendre pour faire avancer les problèmes de sécurité. Restez à l'écoute pour les prochains articles de cette série qui exploreront le potentiel et les défis autour de certains des thèmes.