Dans le monde en constante évolution de la DeFi, il est essentiel de garantir la stabilité et la sécurité du protocole. Lors d'une récente revue de sécurité d'un projet CDP, j'ai observé comment des vulnérabilités spécifiques pourraient survenir dans certaines configurations. Bien que les paramètres actuels de ce projet soient robustes, il est crucial de comprendre ces risques potentiels pour maintenir l'intégrité du protocole.
Cet article vise à explorer le rôle crucial que jouent les frais d'emprunt unique et les frais de rachat dans ce contexte. En examinant des scénarios d'exploitation spécifiques qui pourraient survenir sans ces frais, je démontrerai comment une structure de frais appropriée est essentielle pour prévenir les attaques déstabilisantes, assurant ainsi la sécurité et la viabilité à long terme du protocole.
S'inspirant de l'un des protocoles d'origine, Liquity, et de ses dérivés, de nombreux modèles de CDP (Position de dette garantie) génèrent des stablecoins décentralisés grâce à la sur-collatéralisation. Ces modèles intègrent souvent un ensemble complexe mais sophistiqué de mécanismes conçus pour maintenir l'ancrage au dollar américain tout en assurant la sécurité du protocole dans différentes conditions, minimisant ainsi efficacement le risque de mauvaise dette. Ces protocoles se distinguent par des personnalisations clés, notamment des incitations économiques adaptées qui se rapprochent davantage des objectifs spécifiques du protocole.
Les frais de rachat sont des frais appliqués lorsqu'un utilisateur rachète la stablecoin du protocole pour son collatéral sous-jacent. Cette taxe est conçue pour stabiliser la valeur de la stablecoin en rendant le processus de rachat plus coûteux lorsque les rachats sont fréquents, évitant ainsi les rachats excessifs qui pourraient déstabiliser le protocole.
Les frais de rachat sont calculés en fonction du taux de base du protocole, un paramètre dynamique qui reflète l'activité récente dans le système. Plus précisément, le taux de base augmente à chaque rachat, rendant les rachats ultérieurs plus coûteux.
Cette augmentation est proportionnelle à la fraction de l'approvisionnement total de stablecoins qui est rachetée. Au fil du temps, si aucun rachat n'a lieu, le taux de base décroît progressivement jusqu'à zéro, avec une demi-vie d'environ 12 heures.
Les frais de rachat sont calculés à l'aide de la formule :
Par exemple, si le taux de base est de 1% et qu'un utilisateur rachète 100 stablecoins lorsque le prix du collatéral est de 50 000 $, les frais de rachat seraient :
Ainsi, l'utilisateur recevrait légèrement moins de garantie après avoir pris en compte les frais de rachat. Ce mécanisme garantit que les rachats restent économiquement sensés tout en protégeant le protocole des activités d'arbitrage déstabilisantes.
Les frais d'emprunt sont un autre frais ponctuel facturé lorsque l'utilisateur emprunte des stablecoins contre ses garanties. Ce frais est également basé sur le baseRate, mais il s'applique au moment où les stablecoins sont retirés de la Trove de l'utilisateur (un contrat de coffre-fort contenant les garanties et la dette de l'utilisateur).
Les frais d'emprunt sont calculés comme suit:
Par exemple, si un utilisateur souhaite emprunter 4 000 stablecoins et que le taux de base est fixé à 0,5 %, les frais seraient de :
Cette commission est ajoutée à la dette de l'utilisateur, ce qui signifie que sa dette totale sera le montant emprunté plus la commission (par exemple, 4 000 stablecoins + 20 stablecoins = 4 020 stablecoins).
Ces frais servent également de références souples, influençant indirectement le prix du stablecoin sur le marché en le rendant moins attractif à emprunter ou à échanger dans certaines conditions, contribuant ainsi à maintenir le stablecoin étroitement arrimé à 1 $.
Maintenant, explorons ce qui pourrait se passer si ces frais cruciaux étaient supprimés ou réglés à zéro.
Sans frais de rachat ponctuel, le protocole pourrait involontairement se transformer en une DEX d'échange à glissement nul. Dans un tel scénario, les détenteurs importants de stablecoins pourraient exploiter le mécanisme de rachat pour échanger des stablecoins contre des garanties sans encourir de coûts significatifs, effectuant ainsi des opérations d'arbitrage à grande échelle. Cela pourrait entraîner plusieurs résultats négatifs, car dans cet environnement à glissement nul, les rachats à grande échelle épuiseraient non seulement la liquidité du protocole, mais forceraient également les emprunteurs à vendre leurs garanties au prix du marché actuel. Bien que leur dette soit réduite en conséquence, cette liquidation forcée pourrait augmenter les coûts opérationnels pour les utilisateurs, en particulier si le stablecoin se négocie en dessous de 1 $.
De plus, il existe un risque de front-running des oracles : si un utilisateur remarque qu'une transaction est sur le point de mettre à jour l'oracle du prix du collatéral pour refléter un prix plus élevé, il pourrait rapidement échanger une grande quantité de stablecoin avant la mise à jour du prix. Une fois que le prix du collatéral est mis à jour et augmente, l'utilisateur pourrait ensuite vendre le collatéral échangé avec profit, complétant ainsi un cycle d'arbitrage. Cette pratique n'exploite pas seulement le protocole, mais laisse également les emprunteurs dans une situation désavantageuse, car ils pourraient être contraints de vendre leur collatéral à des prix moins favorables.
L'un des scénarios d'exploitation les plus simples implique la manipulation des frais de rachat pour réduire les coûts. Dans les protocoles où il n'y a pas de frais d'emprunt ponctuel, les utilisateurs peuvent emprunter de grandes quantités de stablecoins, ce qui gonfle artificiellement la dette totale du protocole. Une fois la dette gonflée, ils peuvent échanger leurs stablecoins à des frais réduits, car les frais de rachat sont calculés en fonction du ratio de la taille de rachat à la dette totale du protocole.
Cette manipulation mine la structure tarifaire prévue du protocole, entraînant une réduction des revenus pour le protocole et potentiellement déstabilisant le système. Par exemple, les attaquants peuvent utiliser des prêts flash pour emprunter de grandes quantités de garanties, qu'ils utilisent ensuite pour émettre une quantité importante de stablecoins, augmentant ainsi la dette totale du système. Ils effectuent ensuite une opération de rachat, bénéficiant de la réduction des frais en raison de la dette gonflée, et remboursent enfin le prêt flash, laissant au protocole moins de revenus que prévu et pouvant entraîner une instabilité supplémentaire pour les utilisateurs qui n'avaient pas prévu d'être ciblés pour le rachat.
Une autre vulnérabilité critique découle de la possibilité de forcer le protocole en mode de récupération en un seul bloc, ce qui permet la liquidation de positions avec des ratios de garantie précédemment sains. Cette exploitation repose sur l'utilisation de prêts flash et le minutage de l'attaque autour d'une mise à jour du prix de l'oracle.
L’attaque se déroule comme suit :
L'attaquant utilise d'abord un prêt flash pour emprunter une grande quantité de garanties, qu'il dépose ensuite comme garantie dans le protocole. En utilisant cette garantie, l'attaquant emprunte des stablecoins au taux de ratio de garantie minimum (MCR). L'attaquant peut prendre cette action pour faire baisser le taux de ratio de garantie total (TCR) à 150%, le seuil pour déclencher le mode de récupération.
L’attaquant attend une mise à jour de l’oracle qui reflète une baisse du prix de la garantie. Au fur et à mesure que le nouveau prix inférieur est mis à jour dans le système, la valeur de la garantie diminue, ce qui fait tomber le TCR en dessous de 150 %.
Avec le TCR maintenant inférieur à 150%, le protocole entre automatiquement en mode de récupération. Dans cet état, le protocole permet la liquidation des Troves avec des Ratios de Collatéral (CR) inférieurs au nouveau TCR. L'attaquant peut alors procéder à la liquidation des Troves des autres utilisateurs qui ont désormais un CR inférieur au TCR, leur causant des pertes et profitant des récompenses de liquidation.
S'appuyant sur le scénario d'attaque précédent, cette exploitation avancée permet à un attaquant de forcer le protocole en mode de récupération grâce à un processus de rachat soigneusement conçu. Contrairement à l'attaque précédente, qui peut temporairement ramener le système en mode normal après la liquidation, cette méthode garantit que le système reste en mode de récupération, permettant à l'attaquant d'exploiter à plusieurs reprises la vulnérabilité.
Le problème central, qui se pose lorsque le système prend en charge plusieurs types de garanties, chacune étant gérée par différents gestionnaires de trésorerie, réside dans la possibilité de diminution du ratio total de garantie (TCR) à l'échelle du système après un remboursement, même si la santé des gestionnaires de trésorerie individuels s'améliore. Ce résultat contre-intuitif est le résultat de l'interaction complexe entre les ratios de garantie globaux et locaux.
Par exemple, considérez un scénario où le TCR du système est à 150%.
Si un utilisateur rachète contre une Trove avec un ratio de garantie de 160%, ce qui entraîne la fermeture de cette Trove, le calcul résultant pousserait le TCR en dessous de 150%, déclenchant le mode de récupération.
L’attaque se déroule comme suit :
L'attaquant ouvre une position minimale avec un ratio de garantie légèrement supérieur à 150% dans une Trove soigneusement sélectionnée. Cette configuration est cruciale pour s'assurer que le rachat à l'étape suivante ramène efficacement le TCR en dessous du seuil critique.
L'attaquant utilise un prêt flash pour ouvrir une autre position avec un ratio de garantie au ratio de garantie minimum (MCR) de 110% dans n'importe quel gestionnaire de trésorerie, faisant ainsi tomber le ratio de garantie total (TCR) du système à exactement 150%. Cette étape prépare le système pour le mode de récupération.
L'attaquant rachète ensuite la position ouverte lors de la première étape. Comme cette position a un CR légèrement supérieur à 150%, la racheter fait chuter le TCR en dessous de 150%, déclenchant ainsi le mode de récupération. Le rachat a un impact non seulement sur le Trouvaille spécifique en cours de rachat, mais provoque également un effet systémique qui pousse le TCR en mode de récupération.
Avec le système maintenant en mode de récupération, l'attaquant peut liquider toute position avec un ratio de garantie inférieur à 150%. Ces liquidations pourraient rétablir le TCR à plus de 150%.
L'attaquant peut répéter les étapes si nécessaire, maintenant le système en mode de récupération pour exploiter continuellement les Trésors avec des ratios de garantie inférieurs à 150 %.
Les frais de rachat ponctuels et les frais d'emprunt jouent un rôle crucial dans la réduction des risques associés aux vecteurs d'attaque décrits ci-dessus. En introduisant un coût pour l'emprunt et le rachat, ces frais rendent économiquement irréalisables pour les attaquants d'exécuter des manipulations rentables à grande échelle dans la plupart des cas.
Par exemple, dans le scénario de manipulation des frais de rachat, des frais d'emprunt ponctuels augmenteraient le coût de l'inflation de la dette du système, rendant non rentable pour l'attaquant d'exploiter les frais de rachat. De même, dans les scénarios où l'attaquant cherche à déclencher le mode de récupération, les frais d'emprunt agiraient comme un moyen de dissuasion en augmentant le coût de l'acquisition de grandes quantités de dette afin de manipuler le TCR.
Alors que DeFi évolue, les protocoles seront confrontés à des attaques de plus en plus sophistiquées. Pour rester en tête, il est crucial de comprendre comment différentes fonctionnalités interagissent et peuvent potentiellement créer des vulnérabilités. La sécurité efficace nécessite une compréhension approfondie de la façon dont les différents composants du système interagissent, ainsi qu'une attention particulière aux paramètres qui régissent ces interactions. En anticipant de manière proactive les façons dont les fonctionnalités peuvent se combiner pour créer des vulnérabilités, les concepteurs peuvent construire des protocoles qui sont non seulement sécurisés mais également résilients et adaptables aux défis futurs.
Dans le monde en constante évolution de la DeFi, il est essentiel de garantir la stabilité et la sécurité du protocole. Lors d'une récente revue de sécurité d'un projet CDP, j'ai observé comment des vulnérabilités spécifiques pourraient survenir dans certaines configurations. Bien que les paramètres actuels de ce projet soient robustes, il est crucial de comprendre ces risques potentiels pour maintenir l'intégrité du protocole.
Cet article vise à explorer le rôle crucial que jouent les frais d'emprunt unique et les frais de rachat dans ce contexte. En examinant des scénarios d'exploitation spécifiques qui pourraient survenir sans ces frais, je démontrerai comment une structure de frais appropriée est essentielle pour prévenir les attaques déstabilisantes, assurant ainsi la sécurité et la viabilité à long terme du protocole.
S'inspirant de l'un des protocoles d'origine, Liquity, et de ses dérivés, de nombreux modèles de CDP (Position de dette garantie) génèrent des stablecoins décentralisés grâce à la sur-collatéralisation. Ces modèles intègrent souvent un ensemble complexe mais sophistiqué de mécanismes conçus pour maintenir l'ancrage au dollar américain tout en assurant la sécurité du protocole dans différentes conditions, minimisant ainsi efficacement le risque de mauvaise dette. Ces protocoles se distinguent par des personnalisations clés, notamment des incitations économiques adaptées qui se rapprochent davantage des objectifs spécifiques du protocole.
Les frais de rachat sont des frais appliqués lorsqu'un utilisateur rachète la stablecoin du protocole pour son collatéral sous-jacent. Cette taxe est conçue pour stabiliser la valeur de la stablecoin en rendant le processus de rachat plus coûteux lorsque les rachats sont fréquents, évitant ainsi les rachats excessifs qui pourraient déstabiliser le protocole.
Les frais de rachat sont calculés en fonction du taux de base du protocole, un paramètre dynamique qui reflète l'activité récente dans le système. Plus précisément, le taux de base augmente à chaque rachat, rendant les rachats ultérieurs plus coûteux.
Cette augmentation est proportionnelle à la fraction de l'approvisionnement total de stablecoins qui est rachetée. Au fil du temps, si aucun rachat n'a lieu, le taux de base décroît progressivement jusqu'à zéro, avec une demi-vie d'environ 12 heures.
Les frais de rachat sont calculés à l'aide de la formule :
Par exemple, si le taux de base est de 1% et qu'un utilisateur rachète 100 stablecoins lorsque le prix du collatéral est de 50 000 $, les frais de rachat seraient :
Ainsi, l'utilisateur recevrait légèrement moins de garantie après avoir pris en compte les frais de rachat. Ce mécanisme garantit que les rachats restent économiquement sensés tout en protégeant le protocole des activités d'arbitrage déstabilisantes.
Les frais d'emprunt sont un autre frais ponctuel facturé lorsque l'utilisateur emprunte des stablecoins contre ses garanties. Ce frais est également basé sur le baseRate, mais il s'applique au moment où les stablecoins sont retirés de la Trove de l'utilisateur (un contrat de coffre-fort contenant les garanties et la dette de l'utilisateur).
Les frais d'emprunt sont calculés comme suit:
Par exemple, si un utilisateur souhaite emprunter 4 000 stablecoins et que le taux de base est fixé à 0,5 %, les frais seraient de :
Cette commission est ajoutée à la dette de l'utilisateur, ce qui signifie que sa dette totale sera le montant emprunté plus la commission (par exemple, 4 000 stablecoins + 20 stablecoins = 4 020 stablecoins).
Ces frais servent également de références souples, influençant indirectement le prix du stablecoin sur le marché en le rendant moins attractif à emprunter ou à échanger dans certaines conditions, contribuant ainsi à maintenir le stablecoin étroitement arrimé à 1 $.
Maintenant, explorons ce qui pourrait se passer si ces frais cruciaux étaient supprimés ou réglés à zéro.
Sans frais de rachat ponctuel, le protocole pourrait involontairement se transformer en une DEX d'échange à glissement nul. Dans un tel scénario, les détenteurs importants de stablecoins pourraient exploiter le mécanisme de rachat pour échanger des stablecoins contre des garanties sans encourir de coûts significatifs, effectuant ainsi des opérations d'arbitrage à grande échelle. Cela pourrait entraîner plusieurs résultats négatifs, car dans cet environnement à glissement nul, les rachats à grande échelle épuiseraient non seulement la liquidité du protocole, mais forceraient également les emprunteurs à vendre leurs garanties au prix du marché actuel. Bien que leur dette soit réduite en conséquence, cette liquidation forcée pourrait augmenter les coûts opérationnels pour les utilisateurs, en particulier si le stablecoin se négocie en dessous de 1 $.
De plus, il existe un risque de front-running des oracles : si un utilisateur remarque qu'une transaction est sur le point de mettre à jour l'oracle du prix du collatéral pour refléter un prix plus élevé, il pourrait rapidement échanger une grande quantité de stablecoin avant la mise à jour du prix. Une fois que le prix du collatéral est mis à jour et augmente, l'utilisateur pourrait ensuite vendre le collatéral échangé avec profit, complétant ainsi un cycle d'arbitrage. Cette pratique n'exploite pas seulement le protocole, mais laisse également les emprunteurs dans une situation désavantageuse, car ils pourraient être contraints de vendre leur collatéral à des prix moins favorables.
L'un des scénarios d'exploitation les plus simples implique la manipulation des frais de rachat pour réduire les coûts. Dans les protocoles où il n'y a pas de frais d'emprunt ponctuel, les utilisateurs peuvent emprunter de grandes quantités de stablecoins, ce qui gonfle artificiellement la dette totale du protocole. Une fois la dette gonflée, ils peuvent échanger leurs stablecoins à des frais réduits, car les frais de rachat sont calculés en fonction du ratio de la taille de rachat à la dette totale du protocole.
Cette manipulation mine la structure tarifaire prévue du protocole, entraînant une réduction des revenus pour le protocole et potentiellement déstabilisant le système. Par exemple, les attaquants peuvent utiliser des prêts flash pour emprunter de grandes quantités de garanties, qu'ils utilisent ensuite pour émettre une quantité importante de stablecoins, augmentant ainsi la dette totale du système. Ils effectuent ensuite une opération de rachat, bénéficiant de la réduction des frais en raison de la dette gonflée, et remboursent enfin le prêt flash, laissant au protocole moins de revenus que prévu et pouvant entraîner une instabilité supplémentaire pour les utilisateurs qui n'avaient pas prévu d'être ciblés pour le rachat.
Une autre vulnérabilité critique découle de la possibilité de forcer le protocole en mode de récupération en un seul bloc, ce qui permet la liquidation de positions avec des ratios de garantie précédemment sains. Cette exploitation repose sur l'utilisation de prêts flash et le minutage de l'attaque autour d'une mise à jour du prix de l'oracle.
L’attaque se déroule comme suit :
L'attaquant utilise d'abord un prêt flash pour emprunter une grande quantité de garanties, qu'il dépose ensuite comme garantie dans le protocole. En utilisant cette garantie, l'attaquant emprunte des stablecoins au taux de ratio de garantie minimum (MCR). L'attaquant peut prendre cette action pour faire baisser le taux de ratio de garantie total (TCR) à 150%, le seuil pour déclencher le mode de récupération.
L’attaquant attend une mise à jour de l’oracle qui reflète une baisse du prix de la garantie. Au fur et à mesure que le nouveau prix inférieur est mis à jour dans le système, la valeur de la garantie diminue, ce qui fait tomber le TCR en dessous de 150 %.
Avec le TCR maintenant inférieur à 150%, le protocole entre automatiquement en mode de récupération. Dans cet état, le protocole permet la liquidation des Troves avec des Ratios de Collatéral (CR) inférieurs au nouveau TCR. L'attaquant peut alors procéder à la liquidation des Troves des autres utilisateurs qui ont désormais un CR inférieur au TCR, leur causant des pertes et profitant des récompenses de liquidation.
S'appuyant sur le scénario d'attaque précédent, cette exploitation avancée permet à un attaquant de forcer le protocole en mode de récupération grâce à un processus de rachat soigneusement conçu. Contrairement à l'attaque précédente, qui peut temporairement ramener le système en mode normal après la liquidation, cette méthode garantit que le système reste en mode de récupération, permettant à l'attaquant d'exploiter à plusieurs reprises la vulnérabilité.
Le problème central, qui se pose lorsque le système prend en charge plusieurs types de garanties, chacune étant gérée par différents gestionnaires de trésorerie, réside dans la possibilité de diminution du ratio total de garantie (TCR) à l'échelle du système après un remboursement, même si la santé des gestionnaires de trésorerie individuels s'améliore. Ce résultat contre-intuitif est le résultat de l'interaction complexe entre les ratios de garantie globaux et locaux.
Par exemple, considérez un scénario où le TCR du système est à 150%.
Si un utilisateur rachète contre une Trove avec un ratio de garantie de 160%, ce qui entraîne la fermeture de cette Trove, le calcul résultant pousserait le TCR en dessous de 150%, déclenchant le mode de récupération.
L’attaque se déroule comme suit :
L'attaquant ouvre une position minimale avec un ratio de garantie légèrement supérieur à 150% dans une Trove soigneusement sélectionnée. Cette configuration est cruciale pour s'assurer que le rachat à l'étape suivante ramène efficacement le TCR en dessous du seuil critique.
L'attaquant utilise un prêt flash pour ouvrir une autre position avec un ratio de garantie au ratio de garantie minimum (MCR) de 110% dans n'importe quel gestionnaire de trésorerie, faisant ainsi tomber le ratio de garantie total (TCR) du système à exactement 150%. Cette étape prépare le système pour le mode de récupération.
L'attaquant rachète ensuite la position ouverte lors de la première étape. Comme cette position a un CR légèrement supérieur à 150%, la racheter fait chuter le TCR en dessous de 150%, déclenchant ainsi le mode de récupération. Le rachat a un impact non seulement sur le Trouvaille spécifique en cours de rachat, mais provoque également un effet systémique qui pousse le TCR en mode de récupération.
Avec le système maintenant en mode de récupération, l'attaquant peut liquider toute position avec un ratio de garantie inférieur à 150%. Ces liquidations pourraient rétablir le TCR à plus de 150%.
L'attaquant peut répéter les étapes si nécessaire, maintenant le système en mode de récupération pour exploiter continuellement les Trésors avec des ratios de garantie inférieurs à 150 %.
Les frais de rachat ponctuels et les frais d'emprunt jouent un rôle crucial dans la réduction des risques associés aux vecteurs d'attaque décrits ci-dessus. En introduisant un coût pour l'emprunt et le rachat, ces frais rendent économiquement irréalisables pour les attaquants d'exécuter des manipulations rentables à grande échelle dans la plupart des cas.
Par exemple, dans le scénario de manipulation des frais de rachat, des frais d'emprunt ponctuels augmenteraient le coût de l'inflation de la dette du système, rendant non rentable pour l'attaquant d'exploiter les frais de rachat. De même, dans les scénarios où l'attaquant cherche à déclencher le mode de récupération, les frais d'emprunt agiraient comme un moyen de dissuasion en augmentant le coût de l'acquisition de grandes quantités de dette afin de manipuler le TCR.
Alors que DeFi évolue, les protocoles seront confrontés à des attaques de plus en plus sophistiquées. Pour rester en tête, il est crucial de comprendre comment différentes fonctionnalités interagissent et peuvent potentiellement créer des vulnérabilités. La sécurité efficace nécessite une compréhension approfondie de la façon dont les différents composants du système interagissent, ainsi qu'une attention particulière aux paramètres qui régissent ces interactions. En anticipant de manière proactive les façons dont les fonctionnalités peuvent se combiner pour créer des vulnérabilités, les concepteurs peuvent construire des protocoles qui sont non seulement sécurisés mais également résilients et adaptables aux défis futurs.