Auteur original : Ac_Core, chercheur chez YBB Capital
Préface
Oracle (machine oracle) est un facteur important dans le monde DeFi. Bien que la sécurité des différents protocoles soit généralement héritée par le réseau de contrats intelligents sous-jacent, son fonctionnement normal dépend toujours de la machine oracle. Si la machine oracle d'un protocole est attaquée. détruire, alors l’ensemble de l’accord sera manipulé. Récemment, de nouveaux créateurs de DeFi créent de nouveaux récits en concevant de nouvelles structures de prêts et de produits dérivés, et le changement dans ces protocoles est qu'ils ne s'appuient plus sur des oracles.
Risques et correctifs DeFi
Le plus grand charme de DeFi vient de : la décentralisation. C'est un système financier ouvert sans accord de paiement au sens large. Par rapport à la finance traditionnelle, ses règles, ses bénéfices et même ses risques sont tous plus « obscurs ». La voie est ouverte , mais il reste néanmoins très ouvert.
Cependant, après plusieurs années de développement, des milliards de dollars ont été volés dans le domaine DeFi [1], et même les croyants les plus fanatiques continueront de se demander si ce domaine peut devenir le courant dominant de la finance future. Parmi eux, rien qu’en 2022, les pirates informatiques voleront plus de 3,8 milliards de dollars via les protocoles DeFi et les ponts inter-chaînes, qui est également l’année où le vol est le plus important dans l’histoire du cryptage. Si vous souhaitez permettre à un groupe plus important d’entrer dans le monde crypté et de s’appuyer sur DeFi à l’avenir, la sécurité est la principale considération.
Source : Chainalysis
Risque d'Oracle et "code source"
Nascent estime que le concept de « No Oracle Protocol » fournira fondamentalement à DeFi une architecture technique plus robuste et plus sécurisée. Aujourd'hui, DeFi préfère se définir comme « Primitives » et espère que davantage d'équipes construiront des produits ou des protocoles de portefeuille par-dessus celles-ci. Une fois le contrat mélangé à des dépendances externes, ils hériteront de tous les risques associés. Dans le même temps, le contrat sera mis à niveau afin de supporter une écologie de système plus large, et cette variable de mise à niveau du style de gestion impliquera l'actuel et l'avenir de l'environnement changeant apporte davantage de facteurs de risque. Comme son nom l'indique, l'introduction d'Oracle crée une dépendance à l'égard des données externes, et cette relation entraînera des risques potentiels. Pour cette raison, Dan Elitzer a proposé une nouvelle définition : afin de répondre aux conditions du code source (Primitives), il ne peut s'appuyer sur aucun facteur externe hormis le contrat déployé sur la blockchain, tels que : pas de gouvernance, évolutivité du contrat et machine oracle. .
Mais la réalité est que les protocoles DeFi qui répondent à cette définition de base sont aujourd'hui très rares, dont le plus représentatif est Uniswap V1, mais du point de vue de la sécurité, même Uniswap V2 et V3 qui sont conformes à la définition proposée par Dan Elitzer ci-dessus. sont-ils éligibles, car ils permettent une gouvernance sur certaines fonctionnalités, telles que la clôture des frais de protocole et les niveaux de frais pour l'introduction dans les pools.
Cela dit, cette fonction de gouvernance étroite n'introduit pas de risque systémique en raison des mises à niveau à grande échelle qui existent dans d'autres protocoles. La raison du grand succès d'Uniswap dans toutes les versions jusqu'à présent est qu'il ne possède pas les deux clés de oracle et facteur de chaîne complet.
Il ne fait aucun doute qu'Uniswap est le leader des échanges décentralisés, il a obtenu un grand succès et sur cette base, de nombreuses expériences d'échanges décentralisés sont nées. Par exemple, Uniswap V3 a introduit le concept de positions de liquidité non homogènes, permettant aux fournisseurs de liquidité (LP) de concentrer leur liquidité dans une fourchette spécifique, ce qui permet aux LP de capter davantage de transactions générées dans cette fourchette. , et en tirer profit, mais il y aura également des pertes gratuites à mesure que le prix fluctue. Cela a conduit à une utilisation plus efficace du capital et à la spécialisation du segment LP du marché, conduisant à une gamme d'outils de gestion de position tels qu'Arrakis, Gamma et Sommelier. Bien que cela soit idéal pour les DEX, les protocoles de prêt nécessitent toujours des oracles.
Le temps est venu en mars de cette année, l'accord de prêt d'Euler Finance a été piraté et le montant de la perte s'élevait à 200 millions de dollars américains. Il permet aux utilisateurs de déposer des garanties et d’emprunter de l’argent, et possède des fonctionnalités uniques. En bref, il s'agit d'un problème qui survient dans une fonction spécifique sans contrôle de sécurité, permettant aux utilisateurs de briser les invariants fondamentaux du marché des prêts. Pour le processus détaillé de cette attaque, veuillez lire [2].
Pour les protocoles de prêt, les garanties éligibles sont limitées aux actifs disposant de flux de prix Oracle fiables. Les paramètres du prêt tels que le ratio prêt/valeur [3] sont régis par leur protocole, de sorte que toute créance irrécouvrable relève de la responsabilité du protocole plutôt que des prêteurs individuels. De même, les protocoles dérivés qui s'appuient sur des oracles pour la tarification sans mécanismes internes de découverte des prix sont vulnérables aux décalages de prix, limitant considérablement leur échelle et l'expérience utilisateur. Comme mentionné dans l'avant-propos, cela explique également exactement pourquoi le trader Avraham Eisenberg a réussi à attaquer Mango Markets et à siphonner 116 millions de dollars de l'échange de crypto-monnaie.
Pourquoi Uniswap est actuellement sûr
AMM peut avoir l'invariant de base le plus simple dans n'importe quel code source DeFi (Primitives) : tokenBalanceX * tokenBalanceY == k (comme un produit constant). Par exemple, l'interface Pair dans Uniswap V2 est implémentée sur la base des quatre invariants de fonction suivants :
Menthe : ajouter à k ;
Brûler : soustraire de k ;
Échange : déplacez x et y, gardez k inchangé ;
Skim : réajustez tokenBalanceX * tokenBalanceY pour qu'il soit égal à k.
La méthode sûre d'Uniswap V2 : un simple invariant de base, toutes les fonctions servent cet objectif. La seule chose controversée est qu'il peut basculer le modèle de gouvernance du changement de frais, mais cela ne touchera pas l'invariant principal, affectera simplement la répartition de la propriété du solde des jetons, et c'est précisément en raison de leur simplicité en matière de sécurité (Smart non évolutif contrats et invariants fondamentaux), Uniswap lui-même n’a jamais été piraté.
Reconstruire le protocole de prêt
Source : Auteur Balakov
Récemment, nous avons découvert qu'il existe de nombreux projets de protocoles de prêt sans machines Oracle, tels que Ajna, Ethereum Credit Guild, Automated Tranche Maker de MetaStreet et Blend [4], un protocole hybride lancé conjointement par Blur et Paradig.
Contrairement aux marchés de prêts DeFi traditionnels, Gauntlet ne fixe pas de garanties et ne dispose pas non plus d'un seul oracle universel comme Chainlink qui fournit une « véritable » source de prix d'actifs pour tous les utilisateurs et fonctions de protocole. Au lieu de cela, les emprunteurs doivent évaluer le risque et décider d’exiger certaines garanties de la part des emprunteurs, et doivent mettre à jour leurs critères d’emprunt à mesure que les prix des actifs changent. De manière générale, la façon dont cela fonctionne est que les emprunteurs choisissent la garantie désignée qu'ils sont prêts à accepter, comme le jeton BAYC et le NFT individuel Bored Ape, etc., ils sont prêts à fournir des actifs de référence (tels que l'USDC) que les emprunteurs utilisent comme garantie. , et ils le feront Le ratio entre les actifs de référence et les actifs garantis qui nécessitent la liquidation de l'emprunteur. Enfin, l'emprunteur peut fournir une garantie et emprunter l'actif référencé au taux actuel du marché.
Notez qu’aucun oracle n’est requis puisque le prêteur et l’emprunteur ont convenu que la liquidation du prêt est déterminée en fonction du nombre d’unités de chaque actif plutôt que du ratio du prix en dollars. Toutefois, si la valeur relative en dollars de l’un ou l’autre actif change, les prêteurs ajusteront les conditions des prêts actuels ou futurs pour atteindre ce qu’ils considèrent comme un ratio de garantie sûr.
Le plus grand avantage de ces méthodes est que le protocole est pratiquement indestructible. En effet, chaque prêteur est en fin de compte responsable de la solvabilité de son propre prêt, il n'y a donc pas de concept de « créances douteuses » qui peuvent être supportées par un fonds de trésorerie/d'assurance DAO, ou entre prêteurs à traiter.
Le protocole Blend de Blur 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 leurs propres fonds ». Cela est logique dans le contexte où Blur est la principale plate-forme de négociation pour les traders professionnels de NFT, mais pour l'utilisateur moyen, cela semble beaucoup plus compliqué que d'emprunter et de prêter sur Aave ou Compound.
Nouveaux visages sans Oracle
Selon la définition de Chase Devens, chercheur chez Messari, l'architecture définie sans oracles peut être divisée en deux catégories, à savoir les types hybrides Peer-to-Peer et AMM. Les principales caractéristiques de chacun d’eux sont les suivantes :
d'égal à égal
Prend en charge tout type de garantie en chaîne
L'utilisateur assume les paramètres du prêt et supporte le risque de créances douteuses (le contrat n'assume plus le risque), l'emprunteur ne définit plus les paramètres de taux d'intérêt et de LTV, mais décide lui-même de la comparaison des valeurs et de la suppression de l'oracle du Le mécanisme du protocole signifie que ces prêts peuvent être accordés par n'importe quelle création de garantie en chaîne.
Les positions doivent être gérées activement et pour garantir que la liquidité fournie est utilisée efficacement, les utilisateurs doivent gérer activement leurs positions d'une manière similaire aux emplacements de liquidité centralisés d'Uniswap V3.
Type hybride basé sur AMM (prêts/dérivés - fournisseur de liquidité LPs)
Prend en charge tout type de garantie en chaîne
L'emplacement LP sous-jacent fournit des données sur les prix pour les contrats de compensation et les contrats dérivés, et constitue également le principal marché de liquidation. Permettant au protocole de calculer le résultat des liquidations et des contrats dérivés à partir de son pool de liquidité sous-jacent, la position LP est essentiellement un oracle en soi. De plus, ces emplacements LP constituent un marché primaire pour décharger les stocks de protocoles pendant la liquidation ou l'expiration du contrat sans nécessiter la liquidation des garanties sur des plateformes externes.
Par exemple:
Tout.financier
Ajna est un protocole de prêt conçu pour l'EVM, sans gouvernance, autorisations ou flux de prix externes (oracles). Il peut être utilisé pour emprunter et prêter l’intégralité de notre portefeuille (y compris les NFT). D'autres projets de prêt ont atteint la masse critique de deux problèmes fondamentaux : (1) Le système de gouvernance symbolique est insuffisant pour analyser des risques complexes (2) L'utilisation de flux de prix externes (oracles) limite la portée des actifs à un marché secondaire liquide "Blue Chips". . Ces failles ont provoqué des pertes catastrophiques sur le marché des prêts DeFi et limité la capacité à prendre en charge de nouveaux actifs. Ajna répond à ces problèmes avec quelques innovations clés :
(1) Les prêteurs fournissent une tarification des actifs : lorsque les prêteurs utilisent le protocole Ajna, ils indiqueront au contrat le montant qu’ils souhaitent hypothéquer sur les actifs. Cela leur permet effectivement de saisir leur propre valeur à vie et de la transformer d'un paramètre de gouvernance en un paramètre de marché ;
(2) Découverte automatique des taux : sur chaque marché Ajna, il existe un état d'équilibre déterminé par des indicateurs internes. Si le marché est déséquilibré, n’importe qui peut modifier le taux de change de 10 % toutes les 12 heures. Sinon, n’apportez aucune modification ;
(3) Marge de liquidation : étant donné qu’Ajna n’a pas d’oracle, elle compte sur les utilisateurs pour lui indiquer quand liquider les prêts. Ceci est réalisé en demandant aux liquidateurs de publier des marges pour déclencher la liquidation. S’ils sont honnêtes, ils seront récompensés. Dans le cas contraire, ils sont punis.
Alors à quoi ça sert ? Ces innovations permettent à Ajna de servir « l’ensemble » de l’écosystème. N'importe qui peut créer un marché de prêt avec n'importe quel actif (même les NFT). Fini les processus de gouvernance fastidieux et plus de soucis de liquidité, de marchés secondaires et d’oracles.
Mélange
Source : Achal Srinivasan, Kirby
Blend est un protocole de prêt perpétuel peer-to-peer qui prend en charge toutes les garanties, y compris les NFT. Il met en relation les emprunteurs avec des prêteurs disposés à offrir des taux d'intérêt compétitifs grâce à un protocole de cotation hors chaîne complexe.
Par défaut, les prêts Blend ont un taux d’intérêt fixe et n’expirent jamais. Les emprunteurs peuvent rembourser à tout moment et les prêteurs peuvent liquider leurs positions en déclenchant une vente aux enchères aux Pays-Bas pour trouver de nouveaux prêteurs à de nouveaux taux. Si l'enchère échoue, l'emprunteur est liquidé et le prêteur prend possession de la garantie. L'ensemble présente quatre caractéristiques : indépendant d'oracle, illimité, mobile et peer-to-peer :
Pas d'oracle
De nombreux protocoles DeFi ont besoin de machines Oracle pour déterminer le moment de la liquidation des positions ou de la détermination des taux d'intérêt. En prenant le NFT comme exemple, son prix est difficile à mesurer objectivement, et les mises à jour en temps opportun des prix planchers sont également très difficiles à observer sur la chaîne. La solution implique généralement une partie de confiance ou une manipulation de transaction. L'accord hybride évite toute dépendance à un oracle dans l'accord de base, permettant au taux d'intérêt et au ratio de prêt d'être déterminés par la volonté du prêteur, et la liquidation finale est déclenchée par l'échec de l'enchère néerlandaise ;
sans limites
Certains protocoles DeFi ne prennent en charge que les positions de dette avec des échéances. Ceci n’est pas pratique pour les emprunteurs, qui doivent se rappeler de fermer ou d’ajuster leurs positions avant l’échéance (sous peine de risquer des pénalités telles que la confiscation des NFT). Le processus d'ajustement manuel des positions consomme également du gaz, ce qui réduit également les revenus générés par les prêts. Tant qu'il y a un prêteur prêt à prêter ce montant contre la garantie, Blend ajustera automatiquement la position d'emprunt, et la transaction en chaîne n'est requise que lorsque le taux d'intérêt change ou que l'une des parties souhaite quitter la position ;
fluide
Certains protocoles ne prennent pas en charge la liquidation avant l'échéance, ce qui est plus pratique pour les emprunteurs et logique dans de nombreux cas d'utilisation. Mais cela donne effectivement à l’emprunteur une option de vente, et le prêteur doit choisir entre un prêt à taux plus élevé/inférieur avec une échéance plus courte pour éviter le risque de liquidation de la position. Dans Blend, tant que le prêteur déclenche l'enchère de refinancement, le NFT peut être liquidé lorsque personne n'est disposé à reprendre la dette à n'importe quel taux d'intérêt ;
d'égal à égal
Certains de ces accords mettent en commun l’argent des prêteurs et tentent de gérer les actifs à leur place. Cela signifie s'appuyer fortement sur une gouvernance en chaîne ou centralisée pour définir les paramètres. Blend adopte un modèle peer-to-peer, et chaque prêt est assorti individuellement. Il n'optimise pas la simplicité de la méthode de prêt mais suppose qu'il existe des emprunteurs plus complexes qui peuvent participer à des accords complexes en chaîne et hors chaîne. Ainsi avoir une plus grande autorité pour contrôler leurs propres actifs.
Qu'est-ce que le mode FREI-PI
Selon le modèle FREI-PI expliqué par Brock Elmore, membre de Nascent : "Modèle Function Requirements-Effects-Interactions + Protocol Iniants", ici le contrat SoloMargin (code source) de dYdX est par exemple, il s'agit d'un marché de prêt et d'un contrat pour les transactions à effet de levier, qui constituent un excellent exemple du modèle FREI-PI. Il s’agit du seul marché de prêt parmi les premiers marchés de prêt qui ne présente aucune vulnérabilité liée au marché.
Soyez conscient des abstractions suivantes lorsque vous examinez le code ci-dessous :
exigences de saisie ( _verifyInputs )
操作 ( transformation de données, manipulation d'état )
Exigences de l'état ( _verifyFinalState )
Source : Brock Elmore
Les contrôles-effets-interactions habituels ici sont toujours exécutés. Mais il convient de noter que les contrôles-effets-interactions avec des contrôles supplémentaires ne sont pas équivalents à FREI-PI, bien qu'ils soient similaires mais servent des objectifs différents. À cette fin, les développeurs doivent comprendre la différence : FREI-PI est une abstraction de haut niveau pour la sécurité des protocoles, tandis que CEI est une abstraction de haut niveau pour la sécurité fonctionnelle.
La chose intéressante à propos de cette structure contractuelle est que les utilisateurs peuvent effectuer en continu plusieurs opérations selon leurs propres souhaits, notamment : dépôt, prêt, transaction, transfert, liquidation, etc. Nous supposons que 3 jetons différents sont déposés, que le quatrième jeton est retiré et que le compte est effacé. Cette série d'opérations peut être effectuée en un seul clic.
C'est là toute la puissance du FREI-PI : tant que les invariants fondamentaux du marché des prêts sont valables à la fin de l'appel, les utilisateurs peuvent faire ce qu'ils veulent dans le cadre du protocole. Pour ce contrat, cela sera effectué dans _verifyFinalState, en vérifiant la garantie de chaque compte concerné pour garantir que l'accord est meilleur qu'au début de la transaction.
Cette fonction contient quelques invariants supplémentaires qui complètent les invariants de base et facilitent les fonctions auxiliaires telles que la fermeture du marché, mais ce sont les contrôles de base qui assurent réellement la sécurité du protocole.
Le concept centré sur l'entité est une autre difficulté du FREI-PI, illustré par le marché des prêts et l'invariant de base supposé : les utilisateurs ne peuvent prendre aucune mesure pour placer un compte dans un état de garantie non garantie. D'un point de vue technique, ce n'est pas le seul invariant, mais c'est le seul invariant pour les utilisateurs (il peut être compris comme toujours l'invariant de base du protocole, car l'invariant de l'utilisateur est l'invariant de base du protocole). Il existe généralement deux invariants supplémentaires sur les marchés du crédit :
1. Machine Oracle
D'une manière générale, Chainlink est un bon choix.Sa fonction principale est de fournir des informations en temps réel précises et relativement précises, qui peuvent répondre aux exigences de la plupart des invariants. Dans les rares cas de manipulation ou d'accident, il peut être avantageux de disposer de moins de garanties de précision en temps réel (comme vérifier que la dernière valeur connue est supérieure de plusieurs centaines de pour cent à la valeur actuelle). Pourtant, Cream Finance a subi une attaque de 130 millions de dollars. Pour plus d'informations sur les oracles, veuillez vous référer à : Manipulation des oracles Uniswap V3 TWAP [5] ;
2. Gouvernance
La gouvernance est l'invariant le plus délicat car elle est difficile à conditionner et vise principalement à modifier d'autres invariants, et certaines gouvernances ne peuvent pas être vérifiées par FREI-PI lorsqu'elles fonctionnent. Prenons comme exemple l’opération de gouvernance de Compound qui a détruit le marché des cETH en août 2022. Cette mise à niveau viole l’invariant de la machine oracle. Pour plus de détails, lisez [6].
En pratique, chaque invariant supplémentaire rend le protocole plus difficile à protéger, il devrait donc y en avoir le moins possible. Par conséquent, la complexité est dangereuse et les invariants les plus importants sont les invariants du cœur du protocole, mais comme mentionné ci-dessus, il y aura également des invariants centrés sur l'entité, qui doivent satisfaire aux exigences des invariants de base. /le plus petit ensemble d’invariants est susceptible d’être sûr.
Résumé : L'avenir de la DeFi
Est-ce la meilleure solution pour construire DeFi sur du code source non évolutif (Primitives) et s'éloigner de l'oracle ? Après tout, la flexibilité et la facilité d'utilisation apportées par le protocole DeFi actuel, qui s'appuie sur la gouvernance, l'évolutivité et les machines Oracle, ont également permis à la taille totale du marché d'atteindre des centaines de milliards de dollars. Selon Dan Elitzer, membre de Nascent : "La gouvernance, l'évolutivité et les oracles ne sont pas mauvais en soi. Au contraire, ces éléments ont une grande valeur pratique dans un environnement plus large, mais cela augmentera également la probabilité d'attaque du protocole."
Dans le but de mettre à jour les fonctions ou d'améliorer l'efficacité en fonction des besoins, le code source (primitives) lui-même peut également être remplacé occasionnellement. Lorsque vous choisissez comment créer un protocole DeFi, vous serez confronté à deux choix importants : transmettre toutes les données utilisateur et conditions externes à un protocole unique relativement centralisé, et le confier à un petit nombre de détenteurs de jetons disposés à participer à la gouvernance ? Ou devrions-nous valoriser la propriété de chaque acteur du marché et laisser les utilisateurs décider eux-mêmes de l’accord et du fournisseur de services ?
Les participants et les développeurs de l’ensemble du secteur s’engagent à créer une DeFi plus décentralisée, sans autorisation et hautement composable afin d’améliorer la sécurité et la résilience de l’ensemble du secteur. Concernant l’orientation future du développement de DeFi, nous espérons qu’elle pourra continuer à occuper la part de marché de la finance traditionnelle d’une manière plus sûre et plus efficace.
Explication et références :
[ 1 ]
[2]
[3]
[4]
[5]
[ 6 ]
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
Nouveau récit DeFi ? Un nouveau modèle de sécurité des contrats intelligents sans protocole Oracle
Auteur original : Ac_Core, chercheur chez YBB Capital
Préface
Oracle (machine oracle) est un facteur important dans le monde DeFi. Bien que la sécurité des différents protocoles soit généralement héritée par le réseau de contrats intelligents sous-jacent, son fonctionnement normal dépend toujours de la machine oracle. Si la machine oracle d'un protocole est attaquée. détruire, alors l’ensemble de l’accord sera manipulé. Récemment, de nouveaux créateurs de DeFi créent de nouveaux récits en concevant de nouvelles structures de prêts et de produits dérivés, et le changement dans ces protocoles est qu'ils ne s'appuient plus sur des oracles.
Risques et correctifs DeFi
Le plus grand charme de DeFi vient de : la décentralisation. C'est un système financier ouvert sans accord de paiement au sens large. Par rapport à la finance traditionnelle, ses règles, ses bénéfices et même ses risques sont tous plus « obscurs ». La voie est ouverte , mais il reste néanmoins très ouvert.
Cependant, après plusieurs années de développement, des milliards de dollars ont été volés dans le domaine DeFi [1], et même les croyants les plus fanatiques continueront de se demander si ce domaine peut devenir le courant dominant de la finance future. Parmi eux, rien qu’en 2022, les pirates informatiques voleront plus de 3,8 milliards de dollars via les protocoles DeFi et les ponts inter-chaînes, qui est également l’année où le vol est le plus important dans l’histoire du cryptage. Si vous souhaitez permettre à un groupe plus important d’entrer dans le monde crypté et de s’appuyer sur DeFi à l’avenir, la sécurité est la principale considération.
Source : Chainalysis
Risque d'Oracle et "code source"
Nascent estime que le concept de « No Oracle Protocol » fournira fondamentalement à DeFi une architecture technique plus robuste et plus sécurisée. Aujourd'hui, DeFi préfère se définir comme « Primitives » et espère que davantage d'équipes construiront des produits ou des protocoles de portefeuille par-dessus celles-ci. Une fois le contrat mélangé à des dépendances externes, ils hériteront de tous les risques associés. Dans le même temps, le contrat sera mis à niveau afin de supporter une écologie de système plus large, et cette variable de mise à niveau du style de gestion impliquera l'actuel et l'avenir de l'environnement changeant apporte davantage de facteurs de risque. Comme son nom l'indique, l'introduction d'Oracle crée une dépendance à l'égard des données externes, et cette relation entraînera des risques potentiels. Pour cette raison, Dan Elitzer a proposé une nouvelle définition : afin de répondre aux conditions du code source (Primitives), il ne peut s'appuyer sur aucun facteur externe hormis le contrat déployé sur la blockchain, tels que : pas de gouvernance, évolutivité du contrat et machine oracle. .
Mais la réalité est que les protocoles DeFi qui répondent à cette définition de base sont aujourd'hui très rares, dont le plus représentatif est Uniswap V1, mais du point de vue de la sécurité, même Uniswap V2 et V3 qui sont conformes à la définition proposée par Dan Elitzer ci-dessus. sont-ils éligibles, car ils permettent une gouvernance sur certaines fonctionnalités, telles que la clôture des frais de protocole et les niveaux de frais pour l'introduction dans les pools.
Cela dit, cette fonction de gouvernance étroite n'introduit pas de risque systémique en raison des mises à niveau à grande échelle qui existent dans d'autres protocoles. La raison du grand succès d'Uniswap dans toutes les versions jusqu'à présent est qu'il ne possède pas les deux clés de oracle et facteur de chaîne complet.
Il ne fait aucun doute qu'Uniswap est le leader des échanges décentralisés, il a obtenu un grand succès et sur cette base, de nombreuses expériences d'échanges décentralisés sont nées. Par exemple, Uniswap V3 a introduit le concept de positions de liquidité non homogènes, permettant aux fournisseurs de liquidité (LP) de concentrer leur liquidité dans une fourchette spécifique, ce qui permet aux LP de capter davantage de transactions générées dans cette fourchette. , et en tirer profit, mais il y aura également des pertes gratuites à mesure que le prix fluctue. Cela a conduit à une utilisation plus efficace du capital et à la spécialisation du segment LP du marché, conduisant à une gamme d'outils de gestion de position tels qu'Arrakis, Gamma et Sommelier. Bien que cela soit idéal pour les DEX, les protocoles de prêt nécessitent toujours des oracles.
Le temps est venu en mars de cette année, l'accord de prêt d'Euler Finance a été piraté et le montant de la perte s'élevait à 200 millions de dollars américains. Il permet aux utilisateurs de déposer des garanties et d’emprunter de l’argent, et possède des fonctionnalités uniques. En bref, il s'agit d'un problème qui survient dans une fonction spécifique sans contrôle de sécurité, permettant aux utilisateurs de briser les invariants fondamentaux du marché des prêts. Pour le processus détaillé de cette attaque, veuillez lire [2].
Pour les protocoles de prêt, les garanties éligibles sont limitées aux actifs disposant de flux de prix Oracle fiables. Les paramètres du prêt tels que le ratio prêt/valeur [3] sont régis par leur protocole, de sorte que toute créance irrécouvrable relève de la responsabilité du protocole plutôt que des prêteurs individuels. De même, les protocoles dérivés qui s'appuient sur des oracles pour la tarification sans mécanismes internes de découverte des prix sont vulnérables aux décalages de prix, limitant considérablement leur échelle et l'expérience utilisateur. Comme mentionné dans l'avant-propos, cela explique également exactement pourquoi le trader Avraham Eisenberg a réussi à attaquer Mango Markets et à siphonner 116 millions de dollars de l'échange de crypto-monnaie.
Pourquoi Uniswap est actuellement sûr
AMM peut avoir l'invariant de base le plus simple dans n'importe quel code source DeFi (Primitives) : tokenBalanceX * tokenBalanceY == k (comme un produit constant). Par exemple, l'interface Pair dans Uniswap V2 est implémentée sur la base des quatre invariants de fonction suivants :
Menthe : ajouter à k ;
Brûler : soustraire de k ;
Échange : déplacez x et y, gardez k inchangé ;
Skim : réajustez tokenBalanceX * tokenBalanceY pour qu'il soit égal à k.
La méthode sûre d'Uniswap V2 : un simple invariant de base, toutes les fonctions servent cet objectif. La seule chose controversée est qu'il peut basculer le modèle de gouvernance du changement de frais, mais cela ne touchera pas l'invariant principal, affectera simplement la répartition de la propriété du solde des jetons, et c'est précisément en raison de leur simplicité en matière de sécurité (Smart non évolutif contrats et invariants fondamentaux), Uniswap lui-même n’a jamais été piraté.
Reconstruire le protocole de prêt
Source : Auteur Balakov
Récemment, nous avons découvert qu'il existe de nombreux projets de protocoles de prêt sans machines Oracle, tels que Ajna, Ethereum Credit Guild, Automated Tranche Maker de MetaStreet et Blend [4], un protocole hybride lancé conjointement par Blur et Paradig.
Contrairement aux marchés de prêts DeFi traditionnels, Gauntlet ne fixe pas de garanties et ne dispose pas non plus d'un seul oracle universel comme Chainlink qui fournit une « véritable » source de prix d'actifs pour tous les utilisateurs et fonctions de protocole. Au lieu de cela, les emprunteurs doivent évaluer le risque et décider d’exiger certaines garanties de la part des emprunteurs, et doivent mettre à jour leurs critères d’emprunt à mesure que les prix des actifs changent. De manière générale, la façon dont cela fonctionne est que les emprunteurs choisissent la garantie désignée qu'ils sont prêts à accepter, comme le jeton BAYC et le NFT individuel Bored Ape, etc., ils sont prêts à fournir des actifs de référence (tels que l'USDC) que les emprunteurs utilisent comme garantie. , et ils le feront Le ratio entre les actifs de référence et les actifs garantis qui nécessitent la liquidation de l'emprunteur. Enfin, l'emprunteur peut fournir une garantie et emprunter l'actif référencé au taux actuel du marché.
Notez qu’aucun oracle n’est requis puisque le prêteur et l’emprunteur ont convenu que la liquidation du prêt est déterminée en fonction du nombre d’unités de chaque actif plutôt que du ratio du prix en dollars. Toutefois, si la valeur relative en dollars de l’un ou l’autre actif change, les prêteurs ajusteront les conditions des prêts actuels ou futurs pour atteindre ce qu’ils considèrent comme un ratio de garantie sûr.
Le plus grand avantage de ces méthodes est que le protocole est pratiquement indestructible. En effet, chaque prêteur est en fin de compte responsable de la solvabilité de son propre prêt, il n'y a donc pas de concept de « créances douteuses » qui peuvent être supportées par un fonds de trésorerie/d'assurance DAO, ou entre prêteurs à traiter.
Le protocole Blend de Blur 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 leurs propres fonds ». Cela est logique dans le contexte où Blur est la principale plate-forme de négociation pour les traders professionnels de NFT, mais pour l'utilisateur moyen, cela semble beaucoup plus compliqué que d'emprunter et de prêter sur Aave ou Compound.
Nouveaux visages sans Oracle
Selon la définition de Chase Devens, chercheur chez Messari, l'architecture définie sans oracles peut être divisée en deux catégories, à savoir les types hybrides Peer-to-Peer et AMM. Les principales caractéristiques de chacun d’eux sont les suivantes :
Prend en charge tout type de garantie en chaîne
L'utilisateur assume les paramètres du prêt et supporte le risque de créances douteuses (le contrat n'assume plus le risque), l'emprunteur ne définit plus les paramètres de taux d'intérêt et de LTV, mais décide lui-même de la comparaison des valeurs et de la suppression de l'oracle du Le mécanisme du protocole signifie que ces prêts peuvent être accordés par n'importe quelle création de garantie en chaîne.
Les positions doivent être gérées activement et pour garantir que la liquidité fournie est utilisée efficacement, les utilisateurs doivent gérer activement leurs positions d'une manière similaire aux emplacements de liquidité centralisés d'Uniswap V3.
Prend en charge tout type de garantie en chaîne
L'emplacement LP sous-jacent fournit des données sur les prix pour les contrats de compensation et les contrats dérivés, et constitue également le principal marché de liquidation. Permettant au protocole de calculer le résultat des liquidations et des contrats dérivés à partir de son pool de liquidité sous-jacent, la position LP est essentiellement un oracle en soi. De plus, ces emplacements LP constituent un marché primaire pour décharger les stocks de protocoles pendant la liquidation ou l'expiration du contrat sans nécessiter la liquidation des garanties sur des plateformes externes.
Par exemple:
Tout.financier
Ajna est un protocole de prêt conçu pour l'EVM, sans gouvernance, autorisations ou flux de prix externes (oracles). Il peut être utilisé pour emprunter et prêter l’intégralité de notre portefeuille (y compris les NFT). D'autres projets de prêt ont atteint la masse critique de deux problèmes fondamentaux : (1) Le système de gouvernance symbolique est insuffisant pour analyser des risques complexes (2) L'utilisation de flux de prix externes (oracles) limite la portée des actifs à un marché secondaire liquide "Blue Chips". . Ces failles ont provoqué des pertes catastrophiques sur le marché des prêts DeFi et limité la capacité à prendre en charge de nouveaux actifs. Ajna répond à ces problèmes avec quelques innovations clés :
(1) Les prêteurs fournissent une tarification des actifs : lorsque les prêteurs utilisent le protocole Ajna, ils indiqueront au contrat le montant qu’ils souhaitent hypothéquer sur les actifs. Cela leur permet effectivement de saisir leur propre valeur à vie et de la transformer d'un paramètre de gouvernance en un paramètre de marché ;
(2) Découverte automatique des taux : sur chaque marché Ajna, il existe un état d'équilibre déterminé par des indicateurs internes. Si le marché est déséquilibré, n’importe qui peut modifier le taux de change de 10 % toutes les 12 heures. Sinon, n’apportez aucune modification ;
(3) Marge de liquidation : étant donné qu’Ajna n’a pas d’oracle, elle compte sur les utilisateurs pour lui indiquer quand liquider les prêts. Ceci est réalisé en demandant aux liquidateurs de publier des marges pour déclencher la liquidation. S’ils sont honnêtes, ils seront récompensés. Dans le cas contraire, ils sont punis.
Alors à quoi ça sert ? Ces innovations permettent à Ajna de servir « l’ensemble » de l’écosystème. N'importe qui peut créer un marché de prêt avec n'importe quel actif (même les NFT). Fini les processus de gouvernance fastidieux et plus de soucis de liquidité, de marchés secondaires et d’oracles.
Mélange
Source : Achal Srinivasan, Kirby
Blend est un protocole de prêt perpétuel peer-to-peer qui prend en charge toutes les garanties, y compris les NFT. Il met en relation les emprunteurs avec des prêteurs disposés à offrir des taux d'intérêt compétitifs grâce à un protocole de cotation hors chaîne complexe.
Par défaut, les prêts Blend ont un taux d’intérêt fixe et n’expirent jamais. Les emprunteurs peuvent rembourser à tout moment et les prêteurs peuvent liquider leurs positions en déclenchant une vente aux enchères aux Pays-Bas pour trouver de nouveaux prêteurs à de nouveaux taux. Si l'enchère échoue, l'emprunteur est liquidé et le prêteur prend possession de la garantie. L'ensemble présente quatre caractéristiques : indépendant d'oracle, illimité, mobile et peer-to-peer :
De nombreux protocoles DeFi ont besoin de machines Oracle pour déterminer le moment de la liquidation des positions ou de la détermination des taux d'intérêt. En prenant le NFT comme exemple, son prix est difficile à mesurer objectivement, et les mises à jour en temps opportun des prix planchers sont également très difficiles à observer sur la chaîne. La solution implique généralement une partie de confiance ou une manipulation de transaction. L'accord hybride évite toute dépendance à un oracle dans l'accord de base, permettant au taux d'intérêt et au ratio de prêt d'être déterminés par la volonté du prêteur, et la liquidation finale est déclenchée par l'échec de l'enchère néerlandaise ;
Certains protocoles DeFi ne prennent en charge que les positions de dette avec des échéances. Ceci n’est pas pratique pour les emprunteurs, qui doivent se rappeler de fermer ou d’ajuster leurs positions avant l’échéance (sous peine de risquer des pénalités telles que la confiscation des NFT). Le processus d'ajustement manuel des positions consomme également du gaz, ce qui réduit également les revenus générés par les prêts. Tant qu'il y a un prêteur prêt à prêter ce montant contre la garantie, Blend ajustera automatiquement la position d'emprunt, et la transaction en chaîne n'est requise que lorsque le taux d'intérêt change ou que l'une des parties souhaite quitter la position ;
Certains protocoles ne prennent pas en charge la liquidation avant l'échéance, ce qui est plus pratique pour les emprunteurs et logique dans de nombreux cas d'utilisation. Mais cela donne effectivement à l’emprunteur une option de vente, et le prêteur doit choisir entre un prêt à taux plus élevé/inférieur avec une échéance plus courte pour éviter le risque de liquidation de la position. Dans Blend, tant que le prêteur déclenche l'enchère de refinancement, le NFT peut être liquidé lorsque personne n'est disposé à reprendre la dette à n'importe quel taux d'intérêt ;
Certains de ces accords mettent en commun l’argent des prêteurs et tentent de gérer les actifs à leur place. Cela signifie s'appuyer fortement sur une gouvernance en chaîne ou centralisée pour définir les paramètres. Blend adopte un modèle peer-to-peer, et chaque prêt est assorti individuellement. Il n'optimise pas la simplicité de la méthode de prêt mais suppose qu'il existe des emprunteurs plus complexes qui peuvent participer à des accords complexes en chaîne et hors chaîne. Ainsi avoir une plus grande autorité pour contrôler leurs propres actifs.
Qu'est-ce que le mode FREI-PI
Selon le modèle FREI-PI expliqué par Brock Elmore, membre de Nascent : "Modèle Function Requirements-Effects-Interactions + Protocol Iniants", ici le contrat SoloMargin (code source) de dYdX est par exemple, il s'agit d'un marché de prêt et d'un contrat pour les transactions à effet de levier, qui constituent un excellent exemple du modèle FREI-PI. Il s’agit du seul marché de prêt parmi les premiers marchés de prêt qui ne présente aucune vulnérabilité liée au marché.
Soyez conscient des abstractions suivantes lorsque vous examinez le code ci-dessous :
Source : Brock Elmore
Les contrôles-effets-interactions habituels ici sont toujours exécutés. Mais il convient de noter que les contrôles-effets-interactions avec des contrôles supplémentaires ne sont pas équivalents à FREI-PI, bien qu'ils soient similaires mais servent des objectifs différents. À cette fin, les développeurs doivent comprendre la différence : FREI-PI est une abstraction de haut niveau pour la sécurité des protocoles, tandis que CEI est une abstraction de haut niveau pour la sécurité fonctionnelle.
La chose intéressante à propos de cette structure contractuelle est que les utilisateurs peuvent effectuer en continu plusieurs opérations selon leurs propres souhaits, notamment : dépôt, prêt, transaction, transfert, liquidation, etc. Nous supposons que 3 jetons différents sont déposés, que le quatrième jeton est retiré et que le compte est effacé. Cette série d'opérations peut être effectuée en un seul clic.
C'est là toute la puissance du FREI-PI : tant que les invariants fondamentaux du marché des prêts sont valables à la fin de l'appel, les utilisateurs peuvent faire ce qu'ils veulent dans le cadre du protocole. Pour ce contrat, cela sera effectué dans _verifyFinalState, en vérifiant la garantie de chaque compte concerné pour garantir que l'accord est meilleur qu'au début de la transaction.
Cette fonction contient quelques invariants supplémentaires qui complètent les invariants de base et facilitent les fonctions auxiliaires telles que la fermeture du marché, mais ce sont les contrôles de base qui assurent réellement la sécurité du protocole.
Le concept centré sur l'entité est une autre difficulté du FREI-PI, illustré par le marché des prêts et l'invariant de base supposé : les utilisateurs ne peuvent prendre aucune mesure pour placer un compte dans un état de garantie non garantie. D'un point de vue technique, ce n'est pas le seul invariant, mais c'est le seul invariant pour les utilisateurs (il peut être compris comme toujours l'invariant de base du protocole, car l'invariant de l'utilisateur est l'invariant de base du protocole). Il existe généralement deux invariants supplémentaires sur les marchés du crédit :
1. Machine Oracle
D'une manière générale, Chainlink est un bon choix.Sa fonction principale est de fournir des informations en temps réel précises et relativement précises, qui peuvent répondre aux exigences de la plupart des invariants. Dans les rares cas de manipulation ou d'accident, il peut être avantageux de disposer de moins de garanties de précision en temps réel (comme vérifier que la dernière valeur connue est supérieure de plusieurs centaines de pour cent à la valeur actuelle). Pourtant, Cream Finance a subi une attaque de 130 millions de dollars. Pour plus d'informations sur les oracles, veuillez vous référer à : Manipulation des oracles Uniswap V3 TWAP [5] ;
2. Gouvernance
La gouvernance est l'invariant le plus délicat car elle est difficile à conditionner et vise principalement à modifier d'autres invariants, et certaines gouvernances ne peuvent pas être vérifiées par FREI-PI lorsqu'elles fonctionnent. Prenons comme exemple l’opération de gouvernance de Compound qui a détruit le marché des cETH en août 2022. Cette mise à niveau viole l’invariant de la machine oracle. Pour plus de détails, lisez [6].
En pratique, chaque invariant supplémentaire rend le protocole plus difficile à protéger, il devrait donc y en avoir le moins possible. Par conséquent, la complexité est dangereuse et les invariants les plus importants sont les invariants du cœur du protocole, mais comme mentionné ci-dessus, il y aura également des invariants centrés sur l'entité, qui doivent satisfaire aux exigences des invariants de base. /le plus petit ensemble d’invariants est susceptible d’être sûr.
Résumé : L'avenir de la DeFi
Est-ce la meilleure solution pour construire DeFi sur du code source non évolutif (Primitives) et s'éloigner de l'oracle ? Après tout, la flexibilité et la facilité d'utilisation apportées par le protocole DeFi actuel, qui s'appuie sur la gouvernance, l'évolutivité et les machines Oracle, ont également permis à la taille totale du marché d'atteindre des centaines de milliards de dollars. Selon Dan Elitzer, membre de Nascent : "La gouvernance, l'évolutivité et les oracles ne sont pas mauvais en soi. Au contraire, ces éléments ont une grande valeur pratique dans un environnement plus large, mais cela augmentera également la probabilité d'attaque du protocole."
Dans le but de mettre à jour les fonctions ou d'améliorer l'efficacité en fonction des besoins, le code source (primitives) lui-même peut également être remplacé occasionnellement. Lorsque vous choisissez comment créer un protocole DeFi, vous serez confronté à deux choix importants : transmettre toutes les données utilisateur et conditions externes à un protocole unique relativement centralisé, et le confier à un petit nombre de détenteurs de jetons disposés à participer à la gouvernance ? Ou devrions-nous valoriser la propriété de chaque acteur du marché et laisser les utilisateurs décider eux-mêmes de l’accord et du fournisseur de services ?
Les participants et les développeurs de l’ensemble du secteur s’engagent à créer une DeFi plus décentralisée, sans autorisation et hautement composable afin d’améliorer la sécurité et la résilience de l’ensemble du secteur. Concernant l’orientation future du développement de DeFi, nous espérons qu’elle pourra continuer à occuper la part de marché de la finance traditionnelle d’une manière plus sûre et plus efficace.
Explication et références :
[ 1 ]
[2]
[3]
[4]
[5]
[ 6 ]