Oracle et transactions de front-running - Série de recherche Angle Partie 1

Intermédiaire2/20/2025, 5:32:13 AM
Cet article fournit une analyse approfondie de la conception de l'oracle du protocole Angle et de ses mécanismes de défense contre les transactions de front-running. En combinant Chainlink et Uniswap V3 TWAP, Angle propose une solution innovante visant à protéger le protocole contre les attaques de front-running tout en garantissant que les utilisateurs reçoivent des prix de transaction équitables.

Introduction

Angle permet aux utilisateurs de créer et de brûler des agTokens (stablecoins) en échange d'autres jetons. Les traders peuvent également ouvrir des positions longues sur des paires de garantie/stablecoin disponibles. Il ne s'agit pas de contrats perpétuels traditionnels, car l'équilibre ne dépend pas des taux de financement, et les prix d'exécution proviennent directement de l'oracle. Compte tenu de ces cas d'utilisation, le protocole nécessite une méthode fiable pour évaluer les actifs disponibles afin d'offrir aux utilisateurs des devis équitables tout en se protégeant contre les transactions de front-running. Dans la FAQ de cet article, Samcszun explique pourquoi ce n'est pas aussi simple que d'utiliser les prix au comptant.

Le front-running est un problème de longue date sur le marché. Il s'agit de certains participants qui accèdent à l'information plus tôt que d'autres, ce qui leur permet de tirer parti de cet avantage pour extraire des bénéfices sans risque aux dépens de la contrepartie. Historiquement, prévenir ce phénomène on-chain a été extrêmement difficile. Les coûts élevés et la faible vitesse des transactions Ethereum rendent difficile la mise à jour rapide et fréquente des prix par les oracles. Cela crée des retards entre les prix off-chain et on-chain, offrant ainsi des opportunités aux front-runners pour exploiter la situation.

Tous les protocoles de stablecoin ne sont pas préoccupés par les risques de front-running découlant des retards des oracles. Dans le cas du DAI de Maker, les retards des oracles bénéficient souvent au protocole. Par exemple, si un utilisateur voit que sa position sera liquidée lors de la prochaine mise à jour de l'oracle en raison d'une baisse de prix, elle est incitée à déposer plus de fonds dans le vault, améliorant la santé du protocole et le ratio de garantie.

Synthetix, qui permet des échanges de valeur basés sur des oracles entre des actifs synthétiques et des garanties, est un parfait exemple d'un protocole de stablecoin faisant face à des défis de front-running. Leur article de blog décrit la longue histoire du protocole avec le front-running, y compris certaines attaques passées qu'ils ont subies.

Similar to Synthetix, Angle permet des échanges d'actifs à la valeur de l'oracle avec un glissement de prix nul. En conséquence, Angle est confronté au même problème de front-running. L'équipe principale d'Angle a déployé des efforts importants pour atténuer le front-running. Deux améliorations clés ont été mises en œuvre : un design d'oracle spécifique et une structure de frais dynamique. Dans cet article, nous expliquerons le design d'oracle d'Angle et la logique qui le sous-tend.

Une mise à jour de l'oracle de front-running : Un exemple

Avant de plonger dans la solution d'Angle, essayons d'abord de comprendre comment le front-running peut nuire au protocole. Nous allons prendre un exemple où l'ETH est accepté en garantie pour soutenir la stablecoin d'Angle.

Pas de frais de transaction

Supposons qu'un attaquant surveille le prix ETH hors chaîne et constate que l'oracle Chainlink s'apprête à mettre à jour les données sur chaîne vers un prix plus élevé (de p0 à p1, où p0 < p1). Cet attaquant peut envoyer une transaction pour brûler x stablecoins au prix de p0 en échange de x/p0 valeur en ETH. Ensuite, après la mise à jour du prix à p1, l'attaquant peut le revendre au protocole, réalisant ainsi un profit :

En raison de cette transaction de front-running sur la mise à jour de l'oracle, cette portion du profit est prélevée sur les réserves du protocole. Si nous fixons x = 100 ETH et p1 = 1.01 * p0 (une augmentation de prix de 1 %), cela signifie que l'attaquant a pris 1 ETH sur les réserves du protocole.

Avec frais de transaction

Heureusement, l'augmentation des frais de transaction peut atténuer ce problème, car ils érodent les profits des opérateurs frontaliers et réduisent les opportunités.

Par exemple, si les frais de transaction de minting et de burning sont constants et égaux à f, un attaquant qui brûle x stablecoins à p0 puis les revend au protocole pour de l'ETH à p1 aura le profit final suivant :

Comparé au scénario précédent, les frais réduisent le profit:

Lorsque le frais de transaction est de f = 0,3 % et en suivant l'exemple ci-dessus, le profit de l'attaquant n'est désormais que de 0,39 ETH.

Avec les frais de transaction et deux solutions d'oracle

Pour réduire davantage cette opportunité, nous pouvons compter sur un oracle secondaire pour fournir deux sources de prix potentielles : pC (prix Chainlink) et pU (prix Uniswap). Le protocole peut utiliser le prix le plus favorable (le prix le plus bas à l'émission, lors de l'achat des jetons de l'utilisateur, et le prix le plus élevé à la réduction, lors de la vente d'ETH à l'utilisateur), rendant l'opportunité de front-running moins attrayante.

Imaginez un commerçant essayant de tirer profit de la même opportunité que ci-dessus, en supposant que pC0 < pC1.

D'autre part, nous pouvons considérer que pU est constant et plus proche de pC0. Par conséquent, comme nous le verrons plus tard, en raison de la conception du prix moyen pondéré dans le temps (TWAP) d'Uniswap, pU a tendance à retarder pC.

Dans ce cas, un attaquant cherchant à profiter de l'opportunité potentielle achèterait des jetons du protocole à pC0 (brûlant des stablecoins) et recevrait x(1-f)/pC0 d'ETH. Ensuite, il le revendrait à nouveau à pU1 à un prix plus élevé. Cela entraînerait une perte pour l'attaquant :

Si nous conservons les chiffres de l'exemple, l'attaquant perdrait finalement 0.6 ETH dans cette transaction.

Solution d'Angle

La conception d'Angle vise spécifiquement à éliminer le risque de transactions front-running. Par conséquent, le protocole mettra en œuvre un mécanisme très similaire à l'exemple discuté ci-dessus. Dans cette section, nous explorerons plus en détail les options existantes potentielles, en nous concentrant sur les spécificités de la conception que nous prévoyons de mettre en œuvre et en analysant notre choix de la fenêtre temporelle TWAP.

Options

Les principales solutions d'oracle qui pourraient convenir au cas d'utilisation d'Angle sont :

  • Chain link
  • Uniswap V3 TWAP
  • Maker Feeds

Chainlink est le premier choix évident : c'est une solution d'oracle décentralisée largement utilisée qui fournit plusieurs sources de données couvrant divers actifs. Les prix proviennent de sources multiples et sont relayés à travers un réseau décentralisé, garantissant que les données sont fiables, accessibles et difficiles à manipuler. Cependant, certaines sources de données mettent généralement à jour uniquement après des changements de prix "importants" (comme un changement de 0,5 % dans ETH/USD) ou après un certain laps de temps, ce qui signifie que les prix de Chainlink sont toujours en retard par rapport au prix du marché réel. Par conséquent, les mises à jour des prix de Chainlink peuvent être anticipées en vérifiant les prix hors chaîne ou le mempool.

Le prix moyen pondéré dans le temps (TWAP) de l'Uniswap V3 est une autre solution d'oracle évidente et largement utilisée. Le TWAP peut être consulté à partir du contrat d'Uniswap pour obtenir le prix moyen pondéré dans le temps des jetons dans un pool sur une période de temps spécifique, allant de quelques secondes à 9 jours. Le prix est calculé en fonction du prix moyen des deux jetons dans le pool pendant la période spécifiée. Cela rend la manipulation du TWAP nécessitant une grande quantité de capital et une période de temps plus longue, ce qui est inefficace dans la plupart des cas.

Cependant, puisque le TWAP est le prix moyen des blocs passés, ils sont généralement en retard par rapport aux prix hors chaîne en temps réel ou même aux sources de prix de Chainlink. S'ils sont utilisés seuls, ils ne seraient pas suffisants pour protéger le protocole contre les transactions front-running.

De plus, étant donné que le TWAP ne rapporte que le prix des paires de jetons sur la chaîne, il ne peut pas atteindre l'objectif du protocole qui est de fournir un accès aux actifs qui ne sont pas représentés sur la chaîne (et donc pas dans les pools Uniswap), tels que les stablecoins adossés au forex.

Utiliser les oracles Maker aurait pu être une autre option pour Angle, mais cela signifierait faire confiance à MakerDAO et passer par un processus de gouvernance pour accéder aux données de prix. Les sources de prix seraient également limitées à celles utilisées par Maker, ce qui est insuffisant pour nous car nous visons à accéder aux taux de change forex.

Conception d'Angle : Chainlink + UniV3 TWAP = 💪

Dans cette optique, il a été décidé de combiner l'oracle Chainlink du protocole Angle avec un TWAP Uni V3 de 10 minutes. Cela permet d'obtenir le prix le plus juste possible à tout moment tout en protégeant le protocole contre les attaques de front-running.

En général, les contrats d'Angle compareront les prix des deux canaux et utiliseront le prix le plus favorable au protocole. Avec cette conception, l'attaque frontale du protocole devient plus complexe car, pour exploiter le taux de change du protocole, un attaquant doit manipuler ou attaquer à la fois les oracles.

Plus précisément, notre contrat cherchera le meilleur prix pour tous les paires d'actifs volatils/stablecoin entre Chainlink et Uniswap et utilisera l'oracle forex de Chainlink pour convertir le prix dans la devise fiduciaire requise. Chaque paire de garantie/stablecoin aura un contrat oracle dédié avec sa propre source de prix indépendante.

Comment ça fonctionne?

Par exemple, supposons qu'un utilisateur souhaite trader la paire ETH/agEUR. Notre contrat doit récupérer les prix pour ETH/USD et USD/EUR. Il conservera le meilleur prix pour ETH/USD de Chainlink et le TWAP de 10 minutes du pool ETH/USDC UniV3. Ensuite, il récupérera le prix du forex USD/EUR de Chainlink.

Exemple : Uniswap ETH/USDC TWAP : 1900 USD (le protocole suppose que l'USDC maintient généralement sa parité, c'est-à-dire 1 USDC équivaut à 1 USD) Prix Chainlink ETH : 1850 USD Prix Chainlink USD : 1,16 EUR

Si l'utilisateur souhaite créer des agEUR dans ce cas, le protocole utilisera le prix le plus bas de l'ETH/USD, c'est-à-dire le prix de 1850 USD par ETH de Chainlink. En revanche, si l'utilisateur souhaite brûler des agEUR pour wETH dans la même situation, le protocole utilisera le prix le plus élevé, c'est-à-dire le TWAP de l'ETH/USDC de Uni à 1900. Dans les deux cas, le protocole utilisera le taux USD/EUR de Chainlink de 1,16 pour convertir l'ETH/USD en ETH/EUR.

De même, 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 fermer.

Plus généralement :

  1. Les contrats d'utilisateur qui ont besoin de prix appelleront le contrat d'oracle correspondant.
  2. En fonction du type de transaction, le contrat oracle peut lire des devis à partir de UniV3 TWAP et Chainlink, ou uniquement à partir de Chainlink (par exemple, pour des échanges de stablecoin à stablecoin), et le renvoyer au contrat principal.
  3. Selon l'opération en cours (création, destruction, ouverture ou fermeture), le contrat concerné conserve le meilleur prix pour le protocole et exécute la transaction.

Choisir la fenêtre temporelle Uni V3 TWAP

Le contrat d'Angle utilisera une fenêtre temporelle de 10 minutes pour TWAP. Ce choix a été fait après mûre réflexion, car des fenêtres temporelles différentes peuvent entraîner des structures de prix significativement différentes.

Différences entre les fenêtres temporelles

Dans le cas d'Angle, d'une part, la fenêtre temporelle devrait être suffisamment longue pour fournir un décalage suffisant entre le prix du protocole et le prix au comptant. Cela permet en effet un écart plus important entre les prix de frappe et de combustion pendant les fluctuations de prix, en particulier lorsque le risque de front-running sur Chainlink est doublé. De plus, plus la fenêtre temporelle est longue, plus il est difficile de manipuler le prix TWAP, car les observations récentes ont moins d'impact sur le prix.

D'autre part, le protocole doit toujours offrir aux utilisateurs des devis justes et à jour : utiliser une fenêtre temporelle trop large créera un écart de prix trop important entre le protocole et le prix actuel du marché, tandis que l'utilisation d'une fenêtre temporelle trop étroite ne fournira pas la différence de prix souhaitée.

Comparer les TWAP de 10 minutes et 60 minutes avec les flux de prix Chainlink

Pour vous donner une compréhension de pourquoi nous avons finalement choisi une fenêtre de temps de 10 minutes, voici une comparaison entre les TWAPs ETH/USDC de 10 minutes et 60 minutes et le prix ETH/USD de Chainlink ainsi que le prix de clôture de Coinbase.

Vous pouvez voir comment les taux supérieurs et inférieurs utilisés par le protocole lorsque les utilisateurs émettent/ferment et brûlent/ouvrent passent entre les prix les plus favorables de Chainlink et du TWAP Uniswap pendant les transitions de prix.


Bien que le bloc TWAP de 60 minutes donne souvent des prix très éloignés du marché, le TWAP de 10 minutes fournit un tampon bénéfique pour la source de prix de Chainlink, maintenant le prix suffisamment proche du marché.

Il convient de noter que, comme le montre le premier graphique, plus la volatilité est grande, plus la différence de prix entre Chainlink et Uniswap est grande. En revanche, lorsque les prix restent relativement stables dans le temps, les sources de prix d'Uniswap et de Chainlink sont plus proches les unes des autres. L'utilisation de TWAP comme protection supplémentaire contre le front-running est essentiellement un moyen de facturer dynamiquement plus de frais pendant les périodes de forte volatilité, car le risque de front-running est plus grand en raison des retards des oracles on-chain. Le coût de ces frais effectifs plus élevés est qu'il réduit la capacité des traders d'arbitrage à repricer directement les stablecoins à partir du protocole. Dans la plupart des cas, les prix d'Uniswap et de Chainlink seront très similaires, et les utilisateurs ne remarqueront guère l'utilisation de deux solutions d'oracle. Cependant, pendant les périodes de forte volatilité, lorsque le protocole est exposé au front-running en raison de différences de prix importantes entre les prix actuels et futurs de Chainlink, le prix du protocole différera, le protégeant du front-running.

Focus sur la récupération/remboursement des frais Synthetix

La recherche de l'oracle d'Angle est fortement inspirée par les discussions de gouvernance de Synthetix et les articles de blog connexes sur le front-running. Dans nos recherches, nous avons également rencontré une autre option qu'ils ont mise en œuvre en février 2020, la récupération/remboursement des frais, qui est finalement devenue une solution temporaire.

Ce qu'ils ont fait, c'était d'ajouter une période d'attente aux transactions, pendant laquelle les utilisateurs ne pouvaient pas manipuler le Synth qu'ils voulaient utiliser. Pendant cette période, les oracles pouvaient vérifier si la transaction était affectée par des incohérences, en particulier s'il y avait une différence de prix entre le moment de l'exécution et la fin de la période d'attente. Si une différence de prix existait, la différence devait être payée par l'utilisateur ou le protocole à l'autre partie (protocole ou utilisateur), ou elle serait réglée dans la prochaine transaction avec Synthetix.

Cette solution s'est avérée très efficace pour réduire le front-running, mais ils ont dû allonger la période d'attente et augmenter les frais, ce qui a créé une expérience utilisateur très médiocre pour tous les traders. Cela a également empêché Synth de s'intégrer à d'autres protocoles dans de nombreux cas d'utilisation. Dans le SIP-120, ils ont remplacé cette solution par un plan qui ajoute l'utilisation des oracles 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, réduisant ainsi considérablement le risque de réussite des transactions de front-running.

Pendant les périodes de stress du marché, il est peu probable que le protocole offre aux utilisateurs le meilleur prix possible.

L'impact de ce dernier a été discuté dans le forum de gouvernance Fei. Étant donné que fournir la meilleure exécution des transactions n'est pas l'objectif principal du protocole, nous pensons que la résistance au front-running est plus importante pour garantir la sécurité du protocole. Sur les marchés secondaires pendant les périodes de forte volatilité, une meilleure exécution des transactions sera offerte.

Notre objectif dans le projet Angle est de concevoir un protocole de stablecoin entièrement pris en charge et efficace. Pour y parvenir, il est nécessaire de prendre en compte de nombreux aspects du protocole pour garantir qu'il ne peut pas être trompé pour se retrouver dans une position défavorable, dont la résistance au front-running. Ceci est particulièrement important car la stabilité des stablecoins décentralisés on-chain qui dépendent des oracles repose sur la qualité de leurs oracles.

L’ajout de flux de prix secondaires sous la forme d’un TWAP peut aider le protocole à atténuer les effets négatifs potentiels d’une forte volatilité du marché et les opportunités de premier plan qui se présentent pendant ces périodes.

Enfin, il est important de noter que cette solution d'oracle maintient la flexibilité et la scalabilité. D'une part, la gouvernance d'Angle peut voter et mettre à jour ses contrats d'oracle à tout moment. D'autre part, des oracles peuvent être créés pour n'importe quel flux de prix pris en charge par Chainlink. Il s'agit du niveau de support minimum nécessaire pour réaliser la vision d'Angle de mettre des actifs financiers sur la chaîne de manière efficace en capital !

Avertissement:

  1. Cet article est reproduit à partir de [Communauté Denglink]. Tous les droits d'auteur appartiennent à l'auteur original [Angle]. Si des objections sont formulées à cette réimpression, veuillez contacter le Porte Apprendrel'équipe et ils s'en occuperont rapidement.
  2. Clause de non-responsabilité: Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
  3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.

Oracle et transactions de front-running - Série de recherche Angle Partie 1

Intermédiaire2/20/2025, 5:32:13 AM
Cet article fournit une analyse approfondie de la conception de l'oracle du protocole Angle et de ses mécanismes de défense contre les transactions de front-running. En combinant Chainlink et Uniswap V3 TWAP, Angle propose une solution innovante visant à protéger le protocole contre les attaques de front-running tout en garantissant que les utilisateurs reçoivent des prix de transaction équitables.

Introduction

Angle permet aux utilisateurs de créer et de brûler des agTokens (stablecoins) en échange d'autres jetons. Les traders peuvent également ouvrir des positions longues sur des paires de garantie/stablecoin disponibles. Il ne s'agit pas de contrats perpétuels traditionnels, car l'équilibre ne dépend pas des taux de financement, et les prix d'exécution proviennent directement de l'oracle. Compte tenu de ces cas d'utilisation, le protocole nécessite une méthode fiable pour évaluer les actifs disponibles afin d'offrir aux utilisateurs des devis équitables tout en se protégeant contre les transactions de front-running. Dans la FAQ de cet article, Samcszun explique pourquoi ce n'est pas aussi simple que d'utiliser les prix au comptant.

Le front-running est un problème de longue date sur le marché. Il s'agit de certains participants qui accèdent à l'information plus tôt que d'autres, ce qui leur permet de tirer parti de cet avantage pour extraire des bénéfices sans risque aux dépens de la contrepartie. Historiquement, prévenir ce phénomène on-chain a été extrêmement difficile. Les coûts élevés et la faible vitesse des transactions Ethereum rendent difficile la mise à jour rapide et fréquente des prix par les oracles. Cela crée des retards entre les prix off-chain et on-chain, offrant ainsi des opportunités aux front-runners pour exploiter la situation.

Tous les protocoles de stablecoin ne sont pas préoccupés par les risques de front-running découlant des retards des oracles. Dans le cas du DAI de Maker, les retards des oracles bénéficient souvent au protocole. Par exemple, si un utilisateur voit que sa position sera liquidée lors de la prochaine mise à jour de l'oracle en raison d'une baisse de prix, elle est incitée à déposer plus de fonds dans le vault, améliorant la santé du protocole et le ratio de garantie.

Synthetix, qui permet des échanges de valeur basés sur des oracles entre des actifs synthétiques et des garanties, est un parfait exemple d'un protocole de stablecoin faisant face à des défis de front-running. Leur article de blog décrit la longue histoire du protocole avec le front-running, y compris certaines attaques passées qu'ils ont subies.

Similar to Synthetix, Angle permet des échanges d'actifs à la valeur de l'oracle avec un glissement de prix nul. En conséquence, Angle est confronté au même problème de front-running. L'équipe principale d'Angle a déployé des efforts importants pour atténuer le front-running. Deux améliorations clés ont été mises en œuvre : un design d'oracle spécifique et une structure de frais dynamique. Dans cet article, nous expliquerons le design d'oracle d'Angle et la logique qui le sous-tend.

Une mise à jour de l'oracle de front-running : Un exemple

Avant de plonger dans la solution d'Angle, essayons d'abord de comprendre comment le front-running peut nuire au protocole. Nous allons prendre un exemple où l'ETH est accepté en garantie pour soutenir la stablecoin d'Angle.

Pas de frais de transaction

Supposons qu'un attaquant surveille le prix ETH hors chaîne et constate que l'oracle Chainlink s'apprête à mettre à jour les données sur chaîne vers un prix plus élevé (de p0 à p1, où p0 < p1). Cet attaquant peut envoyer une transaction pour brûler x stablecoins au prix de p0 en échange de x/p0 valeur en ETH. Ensuite, après la mise à jour du prix à p1, l'attaquant peut le revendre au protocole, réalisant ainsi un profit :

En raison de cette transaction de front-running sur la mise à jour de l'oracle, cette portion du profit est prélevée sur les réserves du protocole. Si nous fixons x = 100 ETH et p1 = 1.01 * p0 (une augmentation de prix de 1 %), cela signifie que l'attaquant a pris 1 ETH sur les réserves du protocole.

Avec frais de transaction

Heureusement, l'augmentation des frais de transaction peut atténuer ce problème, car ils érodent les profits des opérateurs frontaliers et réduisent les opportunités.

Par exemple, si les frais de transaction de minting et de burning sont constants et égaux à f, un attaquant qui brûle x stablecoins à p0 puis les revend au protocole pour de l'ETH à p1 aura le profit final suivant :

Comparé au scénario précédent, les frais réduisent le profit:

Lorsque le frais de transaction est de f = 0,3 % et en suivant l'exemple ci-dessus, le profit de l'attaquant n'est désormais que de 0,39 ETH.

Avec les frais de transaction et deux solutions d'oracle

Pour réduire davantage cette opportunité, nous pouvons compter sur un oracle secondaire pour fournir deux sources de prix potentielles : pC (prix Chainlink) et pU (prix Uniswap). Le protocole peut utiliser le prix le plus favorable (le prix le plus bas à l'émission, lors de l'achat des jetons de l'utilisateur, et le prix le plus élevé à la réduction, lors de la vente d'ETH à l'utilisateur), rendant l'opportunité de front-running moins attrayante.

Imaginez un commerçant essayant de tirer profit de la même opportunité que ci-dessus, en supposant que pC0 < pC1.

D'autre part, nous pouvons considérer que pU est constant et plus proche de pC0. Par conséquent, comme nous le verrons plus tard, en raison de la conception du prix moyen pondéré dans le temps (TWAP) d'Uniswap, pU a tendance à retarder pC.

Dans ce cas, un attaquant cherchant à profiter de l'opportunité potentielle achèterait des jetons du protocole à pC0 (brûlant des stablecoins) et recevrait x(1-f)/pC0 d'ETH. Ensuite, il le revendrait à nouveau à pU1 à un prix plus élevé. Cela entraînerait une perte pour l'attaquant :

Si nous conservons les chiffres de l'exemple, l'attaquant perdrait finalement 0.6 ETH dans cette transaction.

Solution d'Angle

La conception d'Angle vise spécifiquement à éliminer le risque de transactions front-running. Par conséquent, le protocole mettra en œuvre un mécanisme très similaire à l'exemple discuté ci-dessus. Dans cette section, nous explorerons plus en détail les options existantes potentielles, en nous concentrant sur les spécificités de la conception que nous prévoyons de mettre en œuvre et en analysant notre choix de la fenêtre temporelle TWAP.

Options

Les principales solutions d'oracle qui pourraient convenir au cas d'utilisation d'Angle sont :

  • Chain link
  • Uniswap V3 TWAP
  • Maker Feeds

Chainlink est le premier choix évident : c'est une solution d'oracle décentralisée largement utilisée qui fournit plusieurs sources de données couvrant divers actifs. Les prix proviennent de sources multiples et sont relayés à travers un réseau décentralisé, garantissant que les données sont fiables, accessibles et difficiles à manipuler. Cependant, certaines sources de données mettent généralement à jour uniquement après des changements de prix "importants" (comme un changement de 0,5 % dans ETH/USD) ou après un certain laps de temps, ce qui signifie que les prix de Chainlink sont toujours en retard par rapport au prix du marché réel. Par conséquent, les mises à jour des prix de Chainlink peuvent être anticipées en vérifiant les prix hors chaîne ou le mempool.

Le prix moyen pondéré dans le temps (TWAP) de l'Uniswap V3 est une autre solution d'oracle évidente et largement utilisée. Le TWAP peut être consulté à partir du contrat d'Uniswap pour obtenir le prix moyen pondéré dans le temps des jetons dans un pool sur une période de temps spécifique, allant de quelques secondes à 9 jours. Le prix est calculé en fonction du prix moyen des deux jetons dans le pool pendant la période spécifiée. Cela rend la manipulation du TWAP nécessitant une grande quantité de capital et une période de temps plus longue, ce qui est inefficace dans la plupart des cas.

Cependant, puisque le TWAP est le prix moyen des blocs passés, ils sont généralement en retard par rapport aux prix hors chaîne en temps réel ou même aux sources de prix de Chainlink. S'ils sont utilisés seuls, ils ne seraient pas suffisants pour protéger le protocole contre les transactions front-running.

De plus, étant donné que le TWAP ne rapporte que le prix des paires de jetons sur la chaîne, il ne peut pas atteindre l'objectif du protocole qui est de fournir un accès aux actifs qui ne sont pas représentés sur la chaîne (et donc pas dans les pools Uniswap), tels que les stablecoins adossés au forex.

Utiliser les oracles Maker aurait pu être une autre option pour Angle, mais cela signifierait faire confiance à MakerDAO et passer par un processus de gouvernance pour accéder aux données de prix. Les sources de prix seraient également limitées à celles utilisées par Maker, ce qui est insuffisant pour nous car nous visons à accéder aux taux de change forex.

Conception d'Angle : Chainlink + UniV3 TWAP = 💪

Dans cette optique, il a été décidé de combiner l'oracle Chainlink du protocole Angle avec un TWAP Uni V3 de 10 minutes. Cela permet d'obtenir le prix le plus juste possible à tout moment tout en protégeant le protocole contre les attaques de front-running.

En général, les contrats d'Angle compareront les prix des deux canaux et utiliseront le prix le plus favorable au protocole. Avec cette conception, l'attaque frontale du protocole devient plus complexe car, pour exploiter le taux de change du protocole, un attaquant doit manipuler ou attaquer à la fois les oracles.

Plus précisément, notre contrat cherchera le meilleur prix pour tous les paires d'actifs volatils/stablecoin entre Chainlink et Uniswap et utilisera l'oracle forex de Chainlink pour convertir le prix dans la devise fiduciaire requise. Chaque paire de garantie/stablecoin aura un contrat oracle dédié avec sa propre source de prix indépendante.

Comment ça fonctionne?

Par exemple, supposons qu'un utilisateur souhaite trader la paire ETH/agEUR. Notre contrat doit récupérer les prix pour ETH/USD et USD/EUR. Il conservera le meilleur prix pour ETH/USD de Chainlink et le TWAP de 10 minutes du pool ETH/USDC UniV3. Ensuite, il récupérera le prix du forex USD/EUR de Chainlink.

Exemple : Uniswap ETH/USDC TWAP : 1900 USD (le protocole suppose que l'USDC maintient généralement sa parité, c'est-à-dire 1 USDC équivaut à 1 USD) Prix Chainlink ETH : 1850 USD Prix Chainlink USD : 1,16 EUR

Si l'utilisateur souhaite créer des agEUR dans ce cas, le protocole utilisera le prix le plus bas de l'ETH/USD, c'est-à-dire le prix de 1850 USD par ETH de Chainlink. En revanche, si l'utilisateur souhaite brûler des agEUR pour wETH dans la même situation, le protocole utilisera le prix le plus élevé, c'est-à-dire le TWAP de l'ETH/USDC de Uni à 1900. Dans les deux cas, le protocole utilisera le taux USD/EUR de Chainlink de 1,16 pour convertir l'ETH/USD en ETH/EUR.

De même, 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 fermer.

Plus généralement :

  1. Les contrats d'utilisateur qui ont besoin de prix appelleront le contrat d'oracle correspondant.
  2. En fonction du type de transaction, le contrat oracle peut lire des devis à partir de UniV3 TWAP et Chainlink, ou uniquement à partir de Chainlink (par exemple, pour des échanges de stablecoin à stablecoin), et le renvoyer au contrat principal.
  3. Selon l'opération en cours (création, destruction, ouverture ou fermeture), le contrat concerné conserve le meilleur prix pour le protocole et exécute la transaction.

Choisir la fenêtre temporelle Uni V3 TWAP

Le contrat d'Angle utilisera une fenêtre temporelle de 10 minutes pour TWAP. Ce choix a été fait après mûre réflexion, car des fenêtres temporelles différentes peuvent entraîner des structures de prix significativement différentes.

Différences entre les fenêtres temporelles

Dans le cas d'Angle, d'une part, la fenêtre temporelle devrait être suffisamment longue pour fournir un décalage suffisant entre le prix du protocole et le prix au comptant. Cela permet en effet un écart plus important entre les prix de frappe et de combustion pendant les fluctuations de prix, en particulier lorsque le risque de front-running sur Chainlink est doublé. De plus, plus la fenêtre temporelle est longue, plus il est difficile de manipuler le prix TWAP, car les observations récentes ont moins d'impact sur le prix.

D'autre part, le protocole doit toujours offrir aux utilisateurs des devis justes et à jour : utiliser une fenêtre temporelle trop large créera un écart de prix trop important entre le protocole et le prix actuel du marché, tandis que l'utilisation d'une fenêtre temporelle trop étroite ne fournira pas la différence de prix souhaitée.

Comparer les TWAP de 10 minutes et 60 minutes avec les flux de prix Chainlink

Pour vous donner une compréhension de pourquoi nous avons finalement choisi une fenêtre de temps de 10 minutes, voici une comparaison entre les TWAPs ETH/USDC de 10 minutes et 60 minutes et le prix ETH/USD de Chainlink ainsi que le prix de clôture de Coinbase.

Vous pouvez voir comment les taux supérieurs et inférieurs utilisés par le protocole lorsque les utilisateurs émettent/ferment et brûlent/ouvrent passent entre les prix les plus favorables de Chainlink et du TWAP Uniswap pendant les transitions de prix.


Bien que le bloc TWAP de 60 minutes donne souvent des prix très éloignés du marché, le TWAP de 10 minutes fournit un tampon bénéfique pour la source de prix de Chainlink, maintenant le prix suffisamment proche du marché.

Il convient de noter que, comme le montre le premier graphique, plus la volatilité est grande, plus la différence de prix entre Chainlink et Uniswap est grande. En revanche, lorsque les prix restent relativement stables dans le temps, les sources de prix d'Uniswap et de Chainlink sont plus proches les unes des autres. L'utilisation de TWAP comme protection supplémentaire contre le front-running est essentiellement un moyen de facturer dynamiquement plus de frais pendant les périodes de forte volatilité, car le risque de front-running est plus grand en raison des retards des oracles on-chain. Le coût de ces frais effectifs plus élevés est qu'il réduit la capacité des traders d'arbitrage à repricer directement les stablecoins à partir du protocole. Dans la plupart des cas, les prix d'Uniswap et de Chainlink seront très similaires, et les utilisateurs ne remarqueront guère l'utilisation de deux solutions d'oracle. Cependant, pendant les périodes de forte volatilité, lorsque le protocole est exposé au front-running en raison de différences de prix importantes entre les prix actuels et futurs de Chainlink, le prix du protocole différera, le protégeant du front-running.

Focus sur la récupération/remboursement des frais Synthetix

La recherche de l'oracle d'Angle est fortement inspirée par les discussions de gouvernance de Synthetix et les articles de blog connexes sur le front-running. Dans nos recherches, nous avons également rencontré une autre option qu'ils ont mise en œuvre en février 2020, la récupération/remboursement des frais, qui est finalement devenue une solution temporaire.

Ce qu'ils ont fait, c'était d'ajouter une période d'attente aux transactions, pendant laquelle les utilisateurs ne pouvaient pas manipuler le Synth qu'ils voulaient utiliser. Pendant cette période, les oracles pouvaient vérifier si la transaction était affectée par des incohérences, en particulier s'il y avait une différence de prix entre le moment de l'exécution et la fin de la période d'attente. Si une différence de prix existait, la différence devait être payée par l'utilisateur ou le protocole à l'autre partie (protocole ou utilisateur), ou elle serait réglée dans la prochaine transaction avec Synthetix.

Cette solution s'est avérée très efficace pour réduire le front-running, mais ils ont dû allonger la période d'attente et augmenter les frais, ce qui a créé une expérience utilisateur très médiocre pour tous les traders. Cela a également empêché Synth de s'intégrer à d'autres protocoles dans de nombreux cas d'utilisation. Dans le SIP-120, ils ont remplacé cette solution par un plan qui ajoute l'utilisation des oracles 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, réduisant ainsi considérablement le risque de réussite des transactions de front-running.

Pendant les périodes de stress du marché, il est peu probable que le protocole offre aux utilisateurs le meilleur prix possible.

L'impact de ce dernier a été discuté dans le forum de gouvernance Fei. Étant donné que fournir la meilleure exécution des transactions n'est pas l'objectif principal du protocole, nous pensons que la résistance au front-running est plus importante pour garantir la sécurité du protocole. Sur les marchés secondaires pendant les périodes de forte volatilité, une meilleure exécution des transactions sera offerte.

Notre objectif dans le projet Angle est de concevoir un protocole de stablecoin entièrement pris en charge et efficace. Pour y parvenir, il est nécessaire de prendre en compte de nombreux aspects du protocole pour garantir qu'il ne peut pas être trompé pour se retrouver dans une position défavorable, dont la résistance au front-running. Ceci est particulièrement important car la stabilité des stablecoins décentralisés on-chain qui dépendent des oracles repose sur la qualité de leurs oracles.

L’ajout de flux de prix secondaires sous la forme d’un TWAP peut aider le protocole à atténuer les effets négatifs potentiels d’une forte volatilité du marché et les opportunités de premier plan qui se présentent pendant ces périodes.

Enfin, il est important de noter que cette solution d'oracle maintient la flexibilité et la scalabilité. D'une part, la gouvernance d'Angle peut voter et mettre à jour ses contrats d'oracle à tout moment. D'autre part, des oracles peuvent être créés pour n'importe quel flux de prix pris en charge par Chainlink. Il s'agit du niveau de support minimum nécessaire pour réaliser la vision d'Angle de mettre des actifs financiers sur la chaîne de manière efficace en capital !

Avertissement:

  1. Cet article est reproduit à partir de [Communauté Denglink]. Tous les droits d'auteur appartiennent à l'auteur original [Angle]. Si des objections sont formulées à cette réimpression, veuillez contacter le Porte Apprendrel'équipe et ils s'en occuperont rapidement.
  2. Clause de non-responsabilité: Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
  3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.
Bắt đầu giao dịch
Đăng ký và giao dịch để nhận phần thưởng USDTEST trị giá
$100
$5500