Oracle en DeFi : la couche de données qui fixe les prix

Un oracle dans DeFi est un middleware qui récupère, vérifie et publie des données externes, le plus souvent des prix de marché, sur la chaîne afin que les contrats intelligents puissent exécuter une logique qu'ils ne peuvent pas calculer uniquement à partir de l'état de la blockchain.

Dans le prêt et les contrats perpétuels, ce prix oracle n'est pas une référence UI, c'est l'entrée exécutable qui décide du pouvoir d'emprunt et des déclencheurs de liquidation.

Points clés

• Un DeFioracleest un middleware qui récupère, vérifie et publie des données externes, le plus souvent des prix de jetons, sur la chaîne afin queles contrats intelligentspuissent exécuter une logique financière.
• Les flux de prix dominent car les protocoles ont besoin d'une référence externe pour évaluerle collatéral, définir le pouvoir d'emprunt et déclencherliquidations automatiquement.
• Les conceptions d'oracles à source unique créent un point de défaillance structurel où une mauvaise impression de prix peut se traduire par de nombreux contrats qui s'exécutent « correctement » en pertes.
• Les protocoles réduisent le risque de manipulation des oracles avec des sources agrégées et un lissage de style TWAP, rendant les distorsions d'un bloc plus difficiles à exploiter.

Comment les prix des oracles deviennent des entrées exécutables pour le prêt et les contrats à terme.

En pratique, un flux d'oracle devient le prix « officiel » d'un protocole en étant la valeur que les contrats sont codés pour lire au moment où ils appliquent les règles. Un marché de prêt tire la dernière mise à jour d'oracle sur la chaîne, convertit le collatéral en valeur dollar, puis vérifie les facteurs de santé, les limites d'emprunt et les seuils de liquidation par rapport à ce chiffre unique.

Les contrats à terme et les systèmes de marge font de même pour le financement, le PnL et les liquidations. C'est pourquoi les détails concernant l'origine du prix, comment il est filtré ou agrégé, et à quelle fréquence il est mis à jour sont importants : l'oracle n'est pas une référence de prix, c'est l'entrée que le moteur de liquidation exécute réellement.

La raison pour laquelle les traders devraient s'en soucier est mécanique. Une fois qu'un prix est sur la chaîne, il devient exécutable. Les protocoles de prêt utilisent ce chiffre pour évaluer le collatéral, définir les limites d'emprunt et décider quand une position est sous-collatéralisée. Les contrats à terme et les systèmes synthétiques l'utilisent pour régler les positions.

Si l'oracle imprime une valeur incorrecte ou obsolète, le contrat intelligent s'exécute toujours de manière déterministe, ce qui signifie que le moteur de liquidation peut se déclencher même si le marché « réel » n'a jamais échangé à ce niveau.

C'est aussi là que la différence entre « un oracle est un widget de prix » et « un oracle est la gestion des risques » apparaît à l'écran. Une interface utilisateur peut avoir du retard, un graphique peut être incorrect, et rien n'a à se produire. Une mise à jour d'oracle est différente car elle est l'entrée pour les mathématiques des contrats.

Une mauvaise impression peut changer de manière atomique le pouvoir d'emprunt de chaque compte qui fait référence au flux, et les liquidations ne sont que le contrat suivant ses règles.

Les prix sont le cas d'utilisation dominant des oracles car la DeFi est principalement une finance collatéralisée. Sans un prix de référence externe, un protocole ne peut pas calculer combien vaut un dépôt en dollars, combien peut être emprunté contre celui-ci, ou si un prêt doit être liquidé.

Pourquoi la DeFi a besoin d'oracles

Les contrats intelligents ne peuvent pas "vérifier Internet" de manière sécurisée car les blockchains sont des systèmes fermés et déterministes. Un contrat ne peut lire que l'état on-chain. Il ne peut pas appeler un échange.APIpoint de terminaison, extraire un site web ou interroger un terminal de données de marché traditionnel et avoir chaque validateur vérifier indépendamment le même résultat.

Cette contrainte crée le problème des oracles : DeFi souhaite automatiser des actions financières qui nécessitent des données de référence externes, mais la chaîne de base ne peut pas importer ces données de manière native. Les oracles existent pour combler cette lacune en prenant des informations hors chaîne et en les rendant disponibles sous une forme que la chaîne peut vérifier et consommer.

C'est pourquoi la question de savoir pourquoi la DeFi a besoin d'oracles n'est pas une question abstraite surdécentralisationIl s'agit de savoir si un marché de prêt peut déterminer en toute sécurité la valeur des garanties et les seuils de liquidation. Si un protocole ne peut pas observer un prix crédible, il ne peut pas établir en toute sécurité la capacité d'emprunt.

S'il utilise un proxy manipulable, comme un marché au comptant à faible liquidité, il peut finir par appliquer des appels de marge basés sur un prix qui n'était "vrai" que pour une seule transaction.

Le graphe de dépendance est important. Tout contrat qui lit un oracle hérite des hypothèses de cet oracle concernant les sources, la cadence de mise à jour et la gestion des pannes. Lorsque plusieurs protocoles partagent le même flux d'oracle, l'oracle devient une pièce d'infrastructure partagée. Cela peut être un atout lorsque le flux est robuste, et un risque systémique lorsque le flux est fragile.

Comment fonctionnent les oracles : des données hors chaîne à l'exécution sur chaîne

Un pipeline d'oracle typique comporte quatre étapes : sélection de la source, récupération des données, agrégation ou validation, et publication sur la blockchain. Les sources peuvent être des prix d'échange ou d'autres API externes. Les opérateurs d'oracle récupèrent ces valeurs, appliquent des règles pour les filtrer ou les combiner, puis publient un résultat sur la blockchain dans une transaction.

Les contrats intelligents lisent cette valeur sur la blockchain et exécutent des actions telles que la mise à jour des ratios de garantie ou le déclenchement de liquidations.

La mise à jour du design est l'endroit où le risque se transforme en timing.Chainlinktrace une ligne claire entre les mises à jour basées sur des push et celles basées sur des pull. Les flux basés sur des push publient sur la chaîne selon un calendrier ou lorsqu'un seuil est atteint, de sorte que la chaîne dispose toujours d'une valeur récente.

Les conceptions basées sur des pull maintiennent les données à jour hors chaîne et ne les apportent sur la chaîne que lorsqu'un utilisateur ou un protocole en a besoin, ce qui déplace qui paie pour la publication et quand la valeur devient exécutable.

Aucun des deux modèles n'est par défaut « le plus sûr ». Les mises à jour basées sur des push peuvent réduire la stagnation mais créer une cadence prévisible que les attaquants peuvent étudier.

Les mises à jour basées sur des pull peuvent réduire le coût sur la chaîne et permettre aux utilisateurs de choisir quand publier, mais elles peuvent également créer des moments où la première mise à jour sur la chaîne après une période de calme devient l'impression critique.

C'est ici que la façon dont fonctionnent les oracles Chainlink importe pour les utilisateurs : le choix entre push et pull change le coût, la fraîcheur et la taille de la fenêtre d'attaque. L'oracle ne se contente pas de délivrer des informations. Il décide quand le moteur de liquidation du protocole reçoit une nouvelle entrée.

Modèles de confiance des oracles et consensus : centralisé vs décentralisé

La première décision de confiance est de savoir si le protocole s'appuie sur un seul éditeur ou plusieurs. Un oracle centralisé est simple : une entité publie la valeur. Le mode de défaillance est également simple. Si cet éditeur se trompe, est compromis ou hors ligne, chaque contrat dépendant hérite du problème.

Les réseaux d'oracles décentralisés visent à supprimer ce point de défaillance unique en utilisant plusieurs opérateurs indépendants et plusieurs sources, puis en les agrégeant en une seule réponse sur la chaîne.

À un niveau élevé, la façon dont les oracles décentralisés atteignent le consensus ressemble à ceci : plusieurs nœuds observent les mêmes données, soumettent leurs observations, et un mécanisme d'agrégation produit une valeur finale que les contrats lisent.

La décentralisation réduit la dépendance à un opérateur unique, mais elle ne garantit pas l'exactitude ou la fraîcheur. Le système a toujours besoin de règles concernant les sources qui comptent, la manière dont les valeurs aberrantes sont traitées et quand les mises à jour sont publiées.

Un flux peut être décentralisé et rester fragile s'il repose sur des marchés peu liquides, a une cadence lente ou a des règles d'agrégation qui laissent une entrée déformée dominer.

C'est aussi là que la différence entre un oracle de prix et un oracle de données importe. Un oracle de prix fournit des prix de marché qui vont directement dans la logique financière comme l'évaluation des garanties et les déclencheurs de liquidation. Un oracle de données est plus large et peut délivrer de nombreux types d'informations externes au-delà des prix.

Les flux de prix se trouvent directement sur le chemin de liquidation pour les positions à effet de levier, c'est pourquoi ils attirent le plus d'attention adversaire.

Attaques et défenses des oracles : manipulation, flashloans et TWAP

Une attaque d'oracle est une exploitation où un attaquant amène un contrat intelligent à consommer des données externes incorrectes, le plus souvent un prix incorrect, et tire profit de l'exécution du contrat contre cette mauvaise entrée. Le contrat n'est pas "confus". Il fait exactement ce pour quoi il a été codé avec la valeur qui lui a été donnée.

La plupart des incidents désagréables qualifiés de hacks d'oracle sont des problèmes de manipulation des prix. L'attaquant cible le marché spécifique auquel l'oracle fait confiance, pousse le prix brièvement, puis utilise cette impression temporaire pour emprunter trop, vider des garanties ou forcer des liquidations. Les flashloans sont l'accélérateur car ils permettent à un attaquant de déployer une grande taille dans une seule transaction.

Halborn rapporte que 62,1 % des attaques de manipulation des prix impliquaient des flashloans, basé sur son analyse des 100 hacks DeFi les plus significatifs jusqu'en 2023. Halborn indique également que des oracles défaillants étaient la principale cause des attaques de manipulation des prix et représentaient plus de 49 % des pertes en 2023 dues à des attaques de manipulation des prix.

Comment les protocoles empêchent la manipulation des oracles revient à rendre les distorsions d'un bloc non rentables. Deux défenses courantes apparaissent de manière répétée. La première est l'agrégation à partir de plusieurs sources et opérateurs, de sorte qu'un seul lieu ou pool ne puisse pas dicter l'impression.

La seconde est le lissage de type TWAP, qui oblige un attaquant à maintenir un prix déformé dans le temps plutôt que pour un trade ou un bloc.

Les conceptions à source unique ne sont pas seulement "moins décentralisées". Elles constituent un point de défaillance structurel unique.

Une mauvaise impression peut se propager dans de nombreux contrats qui lisent tous le même nombre, et la cascade est une exécution parfaitement valide : les limites d'emprunt se mettent à jour, les appels de marge se déclenchent, les liquidations s'exécutent et la mauvaise dette peut être socialisée en fonction de la conception du protocole.

Idées reçues courantes sur les oracles DeFi

"Un oracle n'est qu'un flux de prix" passe à côté de la fonction. L'oracle est le middleware qui récupère, vérifie et publie des données externes sur la blockchain. Les prix sont le cas d'utilisation dominant car ils se branchent directement sur l'évaluation des garanties et la logique de liquidation, mais le concept est plus large qu'un simple ticker.

"Si le contrat intelligent est audité, je suis en sécurité" confond la correction du code avec la correction des entrées. Un code audité peut toujours liquider des positions si l'entrée de l'oracle est incorrecte ou obsolète. Des données de mauvaise qualité entraînent des résultats de mauvaise qualité, ce n'est pas un slogan ici, c'est le chemin de la liquidation.

"Un oracle décentralisé signifie qu'il ne peut pas échouer" traite la décentralisation comme une garantie. L'agrégation réduit la dépendance à un seul opérateur ou source, mais le flux peut toujours être incorrect si les sources sous-jacentes sont rares, corrélées ou manipulables, ou si la cadence de mise à jour crée une obsolescence.

"Les attaques d'oracle sont exotiques" est une idée fausse. Beaucoup sont des manipulations de prix simples, et les flashloans rendent l'exigence de capital temporaire. Le jeu de données de Halborn jusqu'en 2023 place les flashloans dans 62,1 % des attaques de manipulation des prix, ce qui rappelle que les attaquants planifient autour des distorsions d'une transaction.

“SpotDEX"le prix égal au prix juste" est le coûteux pour le long termeactifsUne liquidité faible signifie qu'une seule transaction peut faire varier le prix au comptant de manière significative. Si un oracle lit ce prix au comptant directement sans agrégation ou lissage de type TWAP, le protocole peut finir par traiter une distorsion due à une seule transaction comme étant le marché.

L'analyse

J'ai vu des gens traiter l'oracle comme un détail de fond et ensuite agir surpris lorsqu'une position est liquidée "de nulle part". Le contrat ne s'est pas réveillé et n'a pas choisi la violence. Il a lu un chiffre et exécuté. Si ce chiffre provenait d'un marché peu liquide ou d'un flux d'une seule source, le déclencheur de liquidation était toujours basé sur une entrée fragile.

La posture claire consiste à traiter l'oracle comme un système de marge de courtier, et non comme un graphique. Avant de toucher à un marché de prêt ou à un lieu de contrats perpétuels, je veux trois réponses : d'où vient le prix, comment il se met à jour, et que se passe-t-il s'il est erroné pendant un ou deux blocs.

La statistique de Halborn selon laquelle 62,1 % des attaques de manipulation de prix impliquaient des flashloans rappelle que la "bizarrerie d'un bloc" n'est pas hypothétique. C'est le modèle d'attaque.

Sources

• Halborn
• Chainlink