Oracles et transactions de front-running
TechFlow SélectionTechFlow Sélection
Oracles et transactions de front-running
Explorer en profondeur la solution d'oracle d'Angle et la manière dont elle est conçue pour atténuer les transactions de type front-running.
Dédié à des analyses Web3 approfondiesTraduit par : Communauté Denlian
De nombreuses recherches ont été consacrées à la conception du protocole Angle. Bien que sa structure puisse sembler simple en surface, de nombreux concepts complexes sous-jacents doivent être compris. Dans cette série d'articles, nous approfondirons certains éléments du protocole et expliquerons pourquoi ils ont été conçus ainsi.
Le premier article traite de la solution d'oracle d'Angle et de la manière dont elle a été construite pour atténuer le frontrunning.
Introduction
Angle permet aux utilisateurs de frapper et de brûler des agTokens (stablecoins) contre d'autres jetons. Les traders peuvent également ouvrir des positions longues sur les paires collatéral / stablecoin disponibles. Ce ne sont pas des contrats perpétuels traditionnels, car l'équilibre ne dépend pas des taux de financement, mais les prix d'exécution proviennent directement des oracles.
Compte tenu de ces cas d'utilisation, le protocole a besoin d'un moyen fiable d'évaluer les actifs disponibles afin de proposer des prix équitables aux utilisateurs et de se protéger contre le frontrunning. Dans une FAQ de cet article, Samcszun explique pourquoi cela ne consiste pas simplement à utiliser le prix au comptant.
Le frontrunning est un problème ancien sur les marchés. Il découle du fait que certains participants ont accès à l'information plus tôt que d'autres, ce qui leur permet d'obtenir des profits sans risque au détriment de l'autre partie dans une transaction. Historiquement, empêcher ce phénomène sur blockchain s'est révélé très difficile. Le coût élevé et la lenteur des transactions Ethereum rendaient difficile la mise à jour fréquente et rapide des prix par les oracles. Cela introduisait un délai entre les prix hors chaîne et sur chaîne, permettant aux fraudeurs de tirer profit de cet écart.
Tous les protocoles de stablecoin ne s'inquiètent pas du risque de frontrunning lié au délai des oracles. Dans le cas du DAI de Maker, le délai de l'oracle profite généralement au protocole. Si une personne voit que sa position sera liquidée lors de la prochaine mise à jour de prix due à une baisse, elle est incitée à remettre des fonds dans son coffre, améliorant ainsi la santé du protocole et son ratio de surcollatéralisation.
Synthetix, qui autorise l'échange de valeur entre synthétiques et collatéral selon les données d'oracle, constitue un exemple parfait illustrant le dilemme du frontrunning pour les protocoles de stablecoin. Leur blog résume l'histoire mouvementée du protocole face au frontrunning, y compris certaines attaques subies par le passé.
À l'instar de Synthetix, Angle permet l'échange d'actifs selon la valeur d'oracle sans glissement de prix. Par conséquent, Angle fait face au même problème de frontrunning. L'équipe principale d'Angle a consacré d'importants efforts à prévenir le frontrunning. Deux améliorations majeures ont été mises en œuvre à cet effet : une conception spécifique d'oracle et une structure dynamique de frais. Dans cet article, nous expliquerons la conception de l'oracle d'Angle et les raisons qui la sous-tendent.
Frontrunner une mise à jour d'oracle : un exemple
Avant d'entrer dans les détails de la solution d'Angle, tentons de comprendre comment le frontrunning peut nuire au protocole. Considérons un exemple où l'ETH est accepté comme collatéral soutenant la stablecoin d'Angle.
Absence de frais de transaction
Supposons qu'un attaquant surveille le prix hors chaîne de l'ETH et constate que l'oracle Chainlink va mettre à jour la donnée sur chaîne à un prix plus élevé (passant de p0 à p1, avec p0 < p1). Cet attaquant peut alors envoyer une transaction pour brûler x stablecoins au prix p0, obtenir x/p0 ETH en échange, puis les revendre au protocole après la mise à jour du prix à p1, réalisant ainsi un profit :
En raison de ce frontrunning de la mise à jour d'oracle, cette part de profit est retirée des réserves du protocole. En fixant x = 100 ETH et p1 = 1.01 * p0 (hausse de prix de 1 %), cela signifie que l'attaquant retire 1 ETH des réserves du protocole.
Avec frais de transaction
Heureusement, l'ajout de frais de transaction peut atténuer ce problème, car ils grèvent les profits du frontrunner, réduisant ainsi les opportunités.
Par exemple, si les frais de frappe et de brûlage sont constants et égaux à f, un attaquant qui brûle x stablecoins à p0 puis les revend en ETH au protocole à p1 obtient finalement le profit suivant :
Comparé au cas précédent, les frais réduisent le profit :
Lorsque les frais de transaction sont de f=0.3% et que l'on suit l'exemple ci-dessus, le profit de l'attaquant n'est plus que de 0,39 ETH.
Avec frais de transaction et deux solutions d'oracle
Pour réduire davantage cette opportunité, on peut s'appuyer sur un oracle secondaire fournissant deux sources de prix possibles : pC (prix Chainlink) et pU (prix Uniswap). Le protocole peut exploiter le prix le plus favorable (le prix le plus bas lors de la frappe, c’est-à-dire acheter les jetons de l'utilisateur, et le prix le plus élevé lors de la brûlure, c’est-à-dire vendre de l’ETH à l’utilisateur), rendant ainsi le frontrunning moins attrayant.
-
Imaginons un trader cherchant à profiter de la même opportunité décrite ci-dessus, en supposant pC0 < pC1.
-
D'autre part, on peut considérer que pU reste constant et proche de pC0, donc :
Nous verrons plus tard que, en raison de la conception du TWAP (prix moyenné pondéré dans le temps) d'Uniswap, pU a tendance à retarder pC.
-
Dans ce cas, un attaquant cherchant à profiter de cette opportunité achètera des jetons au protocole à pC0 (brûlure de stablecoins), recevant x(1-f)/pC0 ETH, puis les revendra à pU1 à un prix plus élevé, conduisant à un résultat net donné par :
En conservant les chiffres de l'exemple précédent, l'attaquant subit finalement une perte de 0,6 ETH dans cette opération.
La solution d'Angle
La conception d'Angle vise spécifiquement à éliminer ce risque de frontrunning. Ainsi, le protocole mettra en œuvre un mécanisme très similaire à celui décrit dans l'exemple ci-dessus. Dans cette section, nous examinerons plus en détail les options existantes, nous concentrerons sur les spécificités de la conception retenue et analyserons le choix de la fenêtre temporelle du TWAP.
Options
Les principales solutions d'oracle adaptées au cas d'usage d'Angle sont :
-
Chainlink
-
Uniswap V3 TWAP
-
Maker Feeds
Chainlink est un choix évident : il s'agit d'une solution d'oracle décentralisée largement utilisée, offrant plusieurs sources de données couvrant divers actifs. Ses prix proviennent de multiples sources et transitent par un réseau décentralisé de relais, garantissant fiabilité, accessibilité et résistance à la manipulation. Toutefois, certaines sources ne se mettent à jour qu'après des variations « significatives » du prix (par exemple 0,5 % pour ETH/USD) ou après un certain laps de temps, ce qui signifie que les prix Chainlink retarde toujours le marché réel. Par conséquent, les mises à jour de prix de Chainlink peuvent être frontrunnées en surveillant les prix hors chaîne ou le mempool.
Le temps pondéré moyen des prix (TWAP) d'Uniswap V3 est une autre solution d'oracle populaire et largement adoptée. Le TWAP peut être interrogé depuis les contrats d'Uniswap pour obtenir le prix moyen pondéré dans le temps des jetons d'un pool sur une période allant de quelques secondes à 9 jours. Le prix est calculé comme la moyenne des prix entre les deux jetons sur la durée spécifiée. Grâce à cela, manipuler le TWAP requiert des fonds importants et prend du temps, ce qui le rend inefficace dans la plupart des cas.
Cependant, comme le TWAP représente le prix moyen observé dans les blocs passés, il retarde souvent par rapport aux prix hors chaîne en temps réel, voire par rapport aux sources de prix de Chainlink. S'il est utilisé seul, il ne suffit pas à protéger le protocole contre le frontrunning.
De plus, comme le TWAP ne rapporte que les prix des paires de jetons présentes sur chaîne, il ne répond pas à l'objectif du protocole d'accéder à des actifs non représentés sur chaîne (et donc absents des pools Uniswap), comme les devises étrangères stables.
L'utilisation de Makers Oracles aurait pu constituer une autre option pour Angle. Mais cela impliquerait de faire confiance à MakerDAO et de passer par un processus de gouvernance pour demander l'accès aux données de prix. Les sources seraient également limitées à celles utilisées par Maker, ce qui ne nous convient pas, car nous souhaitons accéder aux taux de change des devises étrangères.
Conception d'Angle : Chainlink + UniV3 TWAP
Étant donné cela, il a été décidé de combiner l'oracle Chainlink du protocole Angle avec un TWAP UniV3 de 10 minutes. Cela permet d'obtenir à tout moment un prix aussi juste que possible tout en protégeant le protocole contre les attaques de frontrunning.
En général, les contrats d'Angle compareront les prix provenant des deux canaux et utiliseront celui le plus favorable au protocole. Grâce à cette conception, le frontrunning devient bien plus complexe, car exploiter le taux du protocole exige de manipuler ou de frontrunner deux oracles simultanément.
Plus précisément, nos contrats récupéreront le meilleur prix disponible sur les paires actifs volatils / stablecoin via Chainlink et le TWAP UniV3 sur 10 minutes, puis convertiront ce prix vers la monnaie fiduciaire souhaitée grâce à l'oracle des changes de Chainlink. Chaque paire collatéral / stablecoin disposera d'un contrat oracle dédié et de ses propres sources de prix indépendantes.
Comment cela fonctionne-t-il ?
Par exemple, supposons qu'un utilisateur souhaite effectuer une transaction sur la paire ETH/agEUR. Notre contrat doit obtenir les prix ETH/USD et USD/EUR. Il conservera le meilleur prix ETH/USD provenant de Chainlink et le TWAP de 10 minutes du pool ETH/USDC UniV3. Ensuite, il récupérera le prix USD/EUR depuis Chainlink.
Exemple : TWAP Uniswap ETH/USDC : 1900 USD (le protocole suppose que USDC maintient généralement son ancrage, soit 1 USDC = 1 USD) ; Prix ETH Chainlink : 1850 USD ; Prix USD Chainlink : 1,16 EUR. Si l'utilisateur souhaite dans ce casfrapper des agEUR, le protocole utilisera le prix ETH/USD le plus bas disponible, soit 1850 USD par ETH selon Chainlink. Inversement, dans le même scénario, si l'utilisateur veutbrûler des agEUR contre du wETH, le protocole utilisera le prix le plus élevé, soit le TWAP Uni ETH/USDC à 1900. Dans les deux cas, le protocole utilisera le taux de change USD/EUR de Chainlink (1,16) pour convertir ETH/USD en ETH/EUR. De façon similaire, le protocole utilisera le prix le plus élevé pour les utilisateurs souhaitant ouvrir un contrat perpétuel, et le prix le plus bas pour ceux souhaitant le clôturer.
Plus généralement :
-
Le contrat utilisateur ayant besoin d’un prix appelle le contrat oracle correspondant.
-
Selon le type de paire, le contrat oracle lit les cotations depuis UniV3 TWAP et Chainlink, ou uniquement depuis Chainlink (par exemple pour les échanges stablecoin contre stablecoin), puis les renvoie au contrat principal.
-
En fonction de l'opération effectuée (frappe, brûlage, ouverture ou clôture), le contrat concerné conserve la meilleure cotation disponible pour le protocole et exécute la transaction.
Choix de la fenêtre temporelle du TWAP Uni V3
Les contrats Angle utiliseront une fenêtre temporelle de 10 minutes pour le TWAP. Ce choix a été soigneusement réfléchi, car différentes fenêtres temporelles peuvent entraîner des structures de prix radicalement différentes.
Différences entre fenêtres temporelles
Dans le cas d'Angle, d'une part, la fenêtre temporelle doit être suffisamment longue pour créer un retard suffisant entre le protocole et le prix au comptant. Cela permet effectivement d'obtenir un écart plus important entre les prix de frappe et de brûlage en cas de volatilité, lorsque le risque de frontrunning sur Chainlink double. En outre, plus la fenêtre est longue, plus il est difficile de manipuler le prix TWAP, car les observations récentes influencent moins le prix final.
D'autre part, le protocole doit continuer à offrir aux utilisateurs des cotations justes et actualisées : une fenêtre trop large crée un écart excessif avec le marché actuel, tandis qu'une fenêtre trop étroite ne fournit pas l'écart de prix souhaité.
Comparer les TWAP de 10 et 60 minutes avec les sources de prix Chainlink
Pour vous donner une idée de notre choix final d'une fenêtre de 10 minutes, voici une comparaison des TWAP ETH/USDC de 10 et 60 minutes avec les prix Chainlink ETH/USD et les cours de clôture Coinbase.
Vous pouvez observer comment, lors des transitions de prix, les taux plancher et plafond utilisés par le protocole lors des opérations de frappe/clôture et brûlage/ouverture, se déplacent entre les prix les plus favorables issus de Chainlink et du TWAP Uniswap.
Bien que les TWAP sur 60 minutes tendent à s'éloigner du marché, le TWAP sur 10 minutes offre un tampon utile par rapport aux sources Chainlink tout en restant suffisamment proche du marché.
Il convient de noter que, d'après le premier graphique, plus la volatilité est élevée, plus l'écart entre les prix Chainlink et Uniswap est important. À l'inverse, lorsque les prix restent relativement stables pendant une période prolongée, les sources Uniswap et Chainlink se rapprochent fortement.
Utiliser le TWAP comme protection supplémentaire contre le frontrunning revient en réalité à percevoir dynamiquement des frais plus élevés durant les périodes de forte volatilité, car c'est précisément à ces moments-là que le risque de frontrunning augmente en raison du délai des oracles sur chaîne. Le coût de ces frais effectifs plus élevés est une capacité réduite pour les traders d'arbitrage de recentrer directement les stablecoins via le protocole.
Dans la plupart des cas, les prix Uniswap et Chainlink seront très proches, rendant presque imperceptible pour les utilisateurs l'utilisation de deux solutions d'oracle. Durant les périodes de haute volatilité, lorsque le protocole pourrait être frontrunné en raison d'une importante différence entre les prix actuels et futurs de Chainlink sur chaîne, les prix du protocole divergeront et celui-ci sera protégé.
Observation sur la récupération / restitution des frais chez Synthetix
La recherche d'Angle sur les oracles s'inspire fortement des discussions de gouvernance de Synthetix sur le frontrunning et de leurs articles de blog associés. Dans nos recherches, nous avons également rencontré une autre option : la récupération / restitution des frais mise en œuvre en février 2020, qui s'est avérée temporaire.
Ils avaient ajouté une période d'attente aux transactions, durant laquelle l'utilisateur ne pouvait pas manipuler le Synth qu’il souhaitait utiliser. Pendant cette période, l'oracle vérifiait si la transaction était affectée par une incohérence, c’est-à-dire une différence de prix entre l’exécution et la fin de la période d’attente. Si tel était le cas, l’écart de prix devait être payé par l’utilisateur ou le protocole à l’autre partie (protocole ou utilisateur), ou compensé lors de la prochaine transaction avec Synthetix.
Cette solution s'est révélée très efficace pour réduire le frontrunning, mais ils ont dû allonger la période d'attente et augmenter les frais, ce qui a gravement détérioré l'expérience utilisateur pour tous les traders. Elle a également empêché la composition des Synths avec d'autres protocoles dans de nombreux cas d'usage. Dans le SIP-120, ils ont remplacé cette solution par une autre ajoutant l'utilisation d'un oracle TWAP pour les grosses transactions.
Conclusion
La conception spécifique de l'oracle d'Angle a deux impacts majeurs sur le protocole :
-
Les attaquants doivent manipuler deux marchés pour tromper le protocole, ce qui réduit considérablement le risque de frontrunning réussi.
-
En période de tension sur le marché, le protocole ne proposera probablement pas le meilleur prix aux utilisateurs.
Ce dernier impact est un sujet discuté sur le forum de gouvernance de Fei. Comme l'exécution optimale des transactions n'est pas l'objectif principal du protocole, nous estimons que la résistance au frontrunning est plus importante pour assurer une sécurité accrue. Les marchés secondaires offriront une meilleure exécution pendant les périodes de forte volatilité.
Notre objectif dans le projet Angle est de concevoir un protocole de stablecoin efficace et pleinement adossé. Cela nécessite d'examiner de nombreux aspects du protocole afin de garantir qu'il ne puisse pas être mis en position défavorable, dont la résistance au frontrunning. Ceci est particulièrement crucial, car la stabilité des stablecoins décentralisés sur chaîne reposant sur des oracles dépend entièrement de la fiabilité de ces derniers.
L'ajout d'une source secondaire de prix sous forme de TWAP aide le protocole à atténuer les effets néfastes potentiels de la forte volatilité du marché, ainsi que les opportunités de frontrunning qui surviennent à ces moments-là.
Enfin, soulignons que cette solution d'oracle reste flexible et extensible. D'une part, la gouvernance d'Angle peut à tout moment voter et mettre à jour ses contrats d'oracle. D'autre part, des oracles peuvent être créés pour toute source de prix prise en charge par Chainlink. Il s'agit d'un soutien minimal permettant de concrétiser la vision d'Angle : intégrer efficacement en termes de capital des actifs financiers sur chaîne.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@UpchainDAO
