Introduction

De l’essor de la DeFi en 2019 à sa maturité progressive d’ici 2024, les problèmes de données ont toujours été au cœur des préoccupations des développeurs. En effet, le fonctionnement de la DeFi repose sur des données on-chain précises et en temps réel, et la qualité des données a un impact direct sur la sécurité, l’efficacité et l’expérience utilisateur des protocoles. Les données sont au cœur de l’échange de valeur et constituent la pierre angulaire des mécanismes de confiance dans les protocoles. Pour les contrats intelligents, les données fonctionnent comme les faits d’entrée, mais les contrats intelligents eux-mêmes ne peuvent pas vérifier activement l’authenticité des données. Au lieu de cela, ils sont entièrement dépendants des données fournies par des sources externes. Cette caractéristique signifie que si les données d’entrée sont falsifiées ou inexactes, le contrat intelligent les accepte passivement, ce qui peut entraîner des risques systémiques. Par conséquent, assurer la décentralisation, la fiabilité et la facilité d’utilisation des données reste un défi permanent. Les défis découlent de deux problèmes principaux : premièrement, la plupart des données sont contrôlées par des institutions ou des plateformes centralisées ; Deuxièmement, l’accès aux données est difficile, car le maintien de la fiabilité sur l’ensemble du pipeline, de la source aux canaux de transmission jusqu’à la destination finale, présente des défis importants.

En tant que pont entre les interactions de données on-chain et off-chain, les oracles deviennent fréquemment les cibles principales des attaques. Une fois qu'un oracle est manipulé, les attaquants peuvent exploiter de fausses informations sur les prix ou le marché pour exécuter des attaques économiques à grande échelle, telles que la manipulation de l'oracle et les attaques de prêt flash qui se sont produites fréquemment en 2021 et 2022. Même en 2024, cette menace persiste, comme le soulignent les récents incidents impliquant UwU Lend et Banana Gun. Ces événements continuent de nous rappeler que la qualité et la sécurité des données de l'oracle déterminent le succès ou l'échec des protocoles individuels et ont directement un impact sur la stabilité de l'ensemble de l'écosystème DeFi.

Cet article se concentrera sur l'application des oracles dans la blockchain, les types d'attaques et les méthodes pour prévenir les manipulations courantes des oracles. Il vise à informer les lecteurs sur les concepts de base et l'importance des oracles, à sensibiliser à la sécurité et à fournir des recommandations pratiques aux développeurs pour intégrer de manière sécurisée des oracles dans les contrats intelligents.

Concepts fondamentaux des oracles

Définition et rôle des Oracles

Un oracle est une interface critique entre la blockchain et le monde extérieur. Il est responsable de l'importation de données hors chaîne dans la blockchain, telles que les prix du marché, les informations météorologiques ou les résultats d'événements, permettant aux contrats intelligents d'accéder à des informations externes. Compte tenu de la nature intrinsèquement fermée des blockchains, les oracles jouent un rôle vital dans des domaines comme la finance décentralisée, les marchés de prédiction, l'assurance et les jeux. Au-delà de répondre aux limites de la blockchain, les oracles facilitent l'interaction entre les contrats intelligents et les données du monde réel, élargissant le champ d'application de la technologie blockchain. Cependant, les oracles sont également confrontés à certains défis et points douloureux:

• L'exactitude des oracles est cruciale. Si la source de données est peu fiable ou compromise, cela peut entraîner une exécution incorrecte des contrats intelligents, entraînant des pertes financières.
• Les oracles eux-mêmes peuvent devenir des cibles d'attaques, comme la manipulation des données de l'oracle pour transmettre de fausses informations, ce qui entraîne une manipulation du marché et perturbe les opérations du protocole.
• Bien que les réseaux d'oracle décentralisés puissent réduire les points de défaillance uniques, des débats persistent concernant leur degré de décentralisation et leur fiabilité. Améliorer la fiabilité et la sécurité des oracles reste un défi technologique clé.

Après avoir compris la définition de base et le rôle des oracles, nous explorerons brièvement les types d'oracles, leurs cas d'utilisation et les risques de sécurité auxquels ils font face.

Types d'oracles: centralisés vs décentralisés

Les oracles peuvent être largement classés en deux modèles de mise en œuvre : centralisés et décentralisés. Les oracles centralisés comme Oraclize s'appuient généralement sur une seule source de données pour fournir des informations hors chaîne. Ils combinent des solutions matérielles et logicielles, en exploitant des technologies telles que TLSNotary et Android Proof pour garantir l'exactitude des données. Ces oracles excellent en termes d'efficacité et de performances stables. Cependant, leur dépendance à l'égard d'une seule source de confiance compromet la nature décentralisée de la blockchain, introduit des goulots d'étranglement à un point unique et limite la scalabilité, ce qui pose des défis en termes de sécurité et d'extensibilité.

En revanche, les oracles décentralisés comme Chainlink privilégient la sécurité du système et la transparence de la confiance. Dans l'architecture de Chainlink, la collecte et la validation des données sont effectuées par de multiples nœuds indépendants, répartis parmi différents participants, réduisant ainsi le risque de points de défaillance uniques. En coordonnant les opérations on-chain et off-chain, Chainlink garantit la diversité et la fiabilité des données. Cette conception décentralisée est particulièrement efficace dans les applications financières, renforçant la résistance de l'oracle aux attaques. Cependant, cette approche implique des compromis en termes d'efficacité et de coût, la rendant moins adaptée aux cas d'utilisation à faible fréquence.

L'importance des oracles décentralisés réside dans la réduction du risque de manipulation de la source de données et la prévention des abus potentiels par des parties de confiance uniques. La décentralisation garantit que les oracles ne dépendent plus de quelques sources de données mais améliorent la sécurité et la fiabilité des données grâce à plusieurs nœuds distribués. Néanmoins, les oracles décentralisés sont également confrontés à des défis, tels que le maintien de mécanismes d'incitation à long terme efficaces et garantir la stabilité globale du réseau oracle. Ensuite, nous explorerons les risques de sécurité associés aux oracles décentralisés et leurs solutions potentielles.

Principes opérationnels et risques des oracles

Oracles avec différentes sources de données : hors chaîne et en chaîne

Dans les opérations Oracle, la source et la méthode de transmission des données affectent directement leur sécurité et leur fiabilité. Les oracles obtiennent des données à partir de deux types de sources : hors chaîne et sur chaîne. L'origine et les méthodes d'acquisition des données diffèrent entre ces deux approches :

• Données hors chaîne : La vitesse de réponse à la volatilité des données hors chaîne dépend des caractéristiques de la source de données et du mécanisme de transmission. Par exemple, les données de prix hors chaîne provenant des échanges sont généralement mises à jour rapidement. Cependant, d'autres données hors chaîne (telles que les données des marchés financiers traditionnels ou les données générées par des calculs complexes) peuvent connaître des retards. La transmission des données hors chaîne repose souvent sur un nombre limité d'institutions privilégiées pour pousser les données vers la blockchain. Ainsi, il est crucial de veiller à ce que ces institutions n'altèrent pas malicieusement les données ou ne poussent pas de mises à jour incorrectes sous la contrainte. Cette dépendance menace potentiellement la crédibilité et l'utilisabilité des données sur les blockchains décentralisées.
• Données de la chaîne : Les données de la chaîne ne nécessitent aucun accès privilégié et sont toujours à jour, offrant de solides capacités en temps réel. Cependant, cette même caractéristique la rend très vulnérable à la manipulation par des attaquants, ce qui pourrait entraîner des conséquences catastrophiques. Les développeurs peuvent facilement accéder aux données de la chaîne en interrogeant les échanges décentralisés (DEX) pour calculer les prix en temps réel.

Oracles On-Chain et Off-Chain
Le choix entre les sources de données hors chaîne et en chaîne dépend des exigences spécifiques du projet et des compromis inhérents à chaque approche. Les développeurs doivent évaluer attentivement et aborder les risques associés. Ce besoin d'équilibre a conduit à des recherches continues sur des méthodes de traitement des données plus sécurisées et plus fiables. Les sections suivantes examineront les principes opérationnels des oracles et leurs vulnérabilités potentielles.

Un bref exemple de développement d'Oracle

Cette section présente un scénario de développement simplifié pour aider les lecteurs à comprendre les cas d'utilisation des oracles dans la blockchain. Dans le développement réel de contrats intelligents de blockchain, il existe plusieurs façons pour un contrat intelligent d'accéder aux données de prix des oracles. Les méthodes courantes comprennent l'appel direct du contrat d'oracle ou l'utilisation de technologies telles que Chainlink CCIP (protocole d'interopérabilité inter-chaînes). Les principales différences entre ces méthodes sont:

1. Si l'application cible réside sur la même blockchain, les développeurs appellent généralement directement le contrat oracle pour récupérer rapidement des informations de prix en temps réel.
2. Pour les applications DeFi multi-chaînes, Chainlink CCIP est couramment utilisé. CCIP fournit un moyen sécurisé de transmettre des données entre différentes blockchains dans des scénarios de chaînes croisées.

Ici, nous démontrons l'utilisation d'un appel direct à un contrat oracle. Imaginez que vous êtes un développeur de contrats intelligents dans l'écosystème Ethereum, et que vous avez besoin de récupérer les données de prix ETH/USD à l'aide d'un oracle dans votre contrat. Tout d'abord, vous définiriez une interface pour vous connecter au contrat oracle et écrire une fonction pour récupérer les données de prix.

Cet exemple de contrat simple montre comment le PrixConsommateurLe contrat récupère les données de prix en temps réel et les utilise pour prendre des décisions. Cela permet de comprendre les interactions de base entre les contrats intelligents et les oracles pour accéder aux données de prix. Ensuite, nous analyserons les risques associés sous deux perspectives :

D'un point de vue contractuel interne, en utilisant des oracles, les attaquants peuvent exploiter des marchés à faible liquidité ou de petits échanges pour manipuler les prix ETH/USD grâce à de grosses transactions, provoquant ainsi des fluctuations de prix anormales. Étant donné que certains oracles s'appuient sur l'agrégation de données provenant de plusieurs plateformes de trading, ces fluctuations anormales peuvent se propager rapidement à la méthode fetchPrice() du PriceConsumer, entraînant une distorsion des prix. Cette situation se produit généralement lorsque les sources de données des oracles sont trop centralisées et que les risques ne sont pas suffisamment diversifiés, rendant ainsi le système plus vulnérable à la manipulation des prix.

Du point de vue d'un contrat externe, l'analyse doit prendre en compte différents scénarios d'application. Supposons que le contrat PriceConsumer soit utilisé sur une plateforme de prêt où les utilisateurs peuvent déposer de l'ETH en guise de garantie pour emprunter d'autres actifs. Les attaquants utilisent d'abord des prêts flash pour emprunter de grosses sommes et déposer temporairement ces fonds dans des Automatic Market Makers (AMM) ou d'autres pools de liquidités. Si l'AMM a une faible profondeur de négociation, une grande quantité d'un seul actif entrant rapidement dans le pool causera directement un glissement de prix.

Dans ce scénario, les transactions importantes de l'attaquant modifient le prix rapporté par l'AMM, qui est ensuite reflété dans le prix manipulé de l'oracle. Après avoir manipulé le prix, l'attaquant pourrait réaliser des bénéfices de différentes manières, telles que :

1. Liquidation des garanties dans les protocoles de prêt : Le prix manipulé pourrait déclencher la liquidation de certains actifs garantis. L'attaquant pourrait alors acheter ces actifs à un prix bas pendant la liquidation pour réaliser un profit.
2. Arbitrage entre plateformes: Si le prix manipulé crée une disparité significative de prix entre les plateformes, l'attaquant pourrait exploiter cette différence pour exécuter des opérations d'arbitrage rentables.

Une fois que l'attaquant a terminé ses opérations, il peut immédiatement retirer les fonds, restaurer le prix de l'AMM et rembourser le flash loan avec intérêts, concluant ainsi le processus de manipulation.

Ensuite, nous allons approfondir la discussion, en analysant des cas spécifiques d'attaques d'oracle, leurs méthodes, et en examinant leur impact destructeur sur les protocoles DeFi et les écosystèmes on-chain, tout en décomposant la logique sous-jacente et les détails techniques clés.

Risques causés directement et indirectement par les oracles

Bien que la manipulation de marché et les attaques d'oracle puissent avoir des conséquences similaires, telles que des distorsions de prix et des pertes d'actifs, leurs méthodes et points de défaillance diffèrent. La plupart des pertes dans l'espace blockchain sont causées par la manipulation de marché plutôt que par des défauts de conception inhérents aux oracles. Les principales distinctions sont les suivantes :

• La manipulation du marché implique de modifier artificiellement l'offre et la demande pour faire monter ou descendre les prix des actifs. Les tactiques courantes incluent les faux échanges et la manipulation entre les marchés. Par exemple, les actifs à faible liquidité sont plus susceptibles d'être manipulés, ce qui peut entraîner des risques de mauvaises créances et de liquidité pour les protocoles DeFi.
• Les attaques Oracle perturbent les sources de données de l'oracle, ce qui le conduit à signaler des prix incohérents avec le marché réel. Cela peut être dû à une manipulation intentionnelle, à des sources de données insuffisantes ou à des vulnérabilités de sécurité de l'oracle. Les attaquants exploitent la différence entre le flux et les prix réels du marché pour manipuler les opérations dans les protocoles DeFi, tels que la collatéralisation ou la liquidation.

Analysons ce cas :

En essence, la manipulation du marché est réalisée en changeant les prix réels du marché, avec des oracles reflétant fidèlement ces prix manipulés, tandis que les attaques d'oracle impliquent de signaler des prix incorrects alors que les prix du marché restent normaux. Après avoir compris la distinction entre les oracles et la manipulation des prix, notre prochaine étape consistera à explorer les différences entre l'acquisition de données on-chain et off-chain, afin de mieux comprendre comment les oracles transmettent les données.

Cas d'attaques liés à Oracle

Parmi les nombreux incidents d'attaque d'oracle, les types courants incluent la manipulation des prix, les prêts flash combinés à des distorsions d'oracle, les erreurs de données hors chaîne et l'exploitation des vulnérabilités de conception du protocole. Ci-dessous, nous discutons de deux cas typiques: l'incident de manipulation des prix de UwU Lend, qui a révélé les vulnérabilités des oracles sur chaîne à la manipulation malveillante, et la défaillance de l'oracle hors chaîne de Synthetix, qui a démontré l'impact profond des erreurs de données externes sur les contrats sur chaîne.

Incident de manipulation de prix de UwU Lend

Le 10 juin 2024, UwU Lend, une plateforme de prêt d'actifs numériques basée sur les chaînes EVM, a subi une attaque entraînant une perte d'environ 19,3 millions de dollars. Cet incident a révélé des vulnérabilités potentielles dans les mécanismes d'oracle au sein des protocoles DeFi.

UwU Lend a utilisé une cryptomonnaie appelée sUSDE, dont le prix était déterminé par un oracle de prix. En tant que composant essentiel du protocole de prêt, la principale responsabilité de l'oracle était d'obtenir et de fournir des données de prix précises pour garantir que des opérations clés telles que le prêt et la liquidation étaient basées sur des prix équitables et stables. Cependant, ce mécanisme essentiel est devenu le point d'entrée de l'attaque.

L'attaquant a manipulé le prix du marché de sUSDE en effectuant des opérations d'échange à grande échelle au sein du pool de liquidités Curve Finance. Cette action a faussé les données de prix générées par l'oracle sur lequel UwU Lend se fiait. En exploitant la valeur gonflée de sUSDE, l'attaquant l'a utilisé comme garantie pour extraire d'autres actifs de UwU Lend, entraînant finalement une importante diminution des actifs pour la plateforme.

La cause principale de cet incident réside dans la conception insuffisante d'UwU Lend pour la lutte contre la manipulation des oracles. Cette vulnérabilité a permis à l'attaquant de manipuler le prix du marché, de fausser les données rapportées par l'oracle et d'exécuter une attaque ciblée. Ce cas met en évidence une lacune courante dans les plates-formes DeFi - de faibles mécanismes de lutte contre la manipulation dans les oracles, en particulier dans des environnements de marché à faible liquidité, où ces risques sont plus prononcés.

Il convient de noter la similitude entre cet incident et les attaques de prêt flash. Les attaques de prêt flash impliquent généralement la création d'anomalies de prix grâce à des flux de capitaux substantiels et à court terme, perturbant ainsi les mécanismes de rétroaction des prix des oracles pour réaliser l'arbitrage d'actifs ou d'autres objectifs malveillants. Cette similitude souligne davantage l'importance de conceptions anti-manipulation robustes dans les oracles, composants critiques de la sécurité du système DeFi.

À l'avenir, les plateformes DeFi devraient se concentrer sur des stratégies telles que l'agrégation de données de prix provenant de plusieurs sources, l'optimisation des fréquences de mise à jour des prix et la surveillance des prix anormaux lors de la construction de mécanismes oracle. Renforcer les capacités de lutte contre la manipulation peut réduire les risques systémiques causés par les défaillances ponctuelles ou la volatilité du marché.

Échec de l'oracle Synthetix

Le 25 juin 2019, Synthetix, un protocole de liquidité dérivée sur Ethereum, a connu une défaillance critique de son système de l'oraclet de prix hors chaîne personnalisé, ce qui a entraîné une transaction unique générant d'énormes profits inattendus. Synthetix s'appuyait sur des sources confidentielles pour son flux de prix, agrégeant et publiant les prix sur la chaîne à intervalles réguliers afin de fournir aux utilisateurs des prix de négociation pour des actifs synthétiques longs ou courts.

Cependant, l'un des canaux de prix a rapporté de manière erronée le taux de change du won coréen (KRW) à 1 000 fois sa valeur réelle. Le système n'a pas réussi à filtrer ces données anormales, ce qui a conduit à l'acceptation et à la publication du prix incorrect sur la chaîne. Un robot de trading a détecté cette erreur et a rapidement exécuté des opérations d'achat et de vente sur le marché sKRW, amassant ainsi des bénéfices substantiels grâce à l'arbitrage. La découverte rapide de ce problème par l'équipe leur a permis de négocier avec le trader, qui a restitué les bénéfices en échange d'une prime de bug, évitant ainsi des pertes potentielles dépassant 1 milliard de dollars.

Bien que l'équipe Synthetix ait mis en place des mesures pour agréger les données de prix provenant de plusieurs sources afin de se prémunir contre les inexactitudes d'une source unique, cet incident a mis en évidence les risques inhérents aux oracles de données hors chaîne. Lorsque les sources de données en amont commettent des erreurs, les contrats en chaîne n'ont aucune visibilité sur le processus de calcul des prix et ne peuvent donc pas détecter automatiquement les anomalies.

Mesures préventives

Les cas ci-dessus mettent en évidence que les défis auxquels les oracles font face vont au-delà de l'exactitude des sources de données, y compris la résistance à la manipulation et la sécurité de l'intégration des données hors chaîne. En conséquence, la prévention des attaques des oracles revêt une importance primordiale. Renforcer la sécurité, la fiabilité et les capacités anti-manipulation des oracles devient un facteur clé lors de leur conception et de leur utilisation. Dans cette section, nous explorons des mesures efficaces pour contrer différents types d'attaques et renforcer la sécurité globale des systèmes d'oracle.

1. Utilisez plusieurs sources de données pour garantir l'exactitude des données

Analyse de cas: Dans l'incident de manipulation des prix d'UwU Lend, les attaquants ont réussi à manipuler l'oracle des prix d'UwU Lend en influençant le prix du sUSDE dans le pool de Curve Finance. En exploitant la vulnérabilité de manipulation des prix, les attaquants ont extrait des actifs que le système n'a pas réussi à évaluer correctement. Si UwU Lend avait utilisé plusieurs sources de données pour déterminer le prix du sUSDE, le système aurait pu vérifier les prix via d'autres sources, réduisant ainsi le risque d'attaque.

Analyse approfondie : Cet incident a impliqué une manipulation des prix et a exposé des problèmes liés à une liquidité insuffisante. Lorsqu'un jeton manque de liquidité sur le marché, la faible profondeur de négociation rend son prix facilement influencé par un petit nombre de transactions, augmentant ainsi la vulnérabilité de l'oracle. Par conséquent, lors du lancement de nouveaux jetons, les équipes de projet doivent évaluer soigneusement la liquidité du marché pour éviter toute distorsion des prix et les risques de sécurité associés. Par exemple, des protocoles de prêt tels que Aave, Kamino et Scallop imposent des limitations plus strictes aux jetons à faible liquidité dans leurs conceptions pour assurer la stabilité et la sécurité du marché.

Approche d'optimisation: Pour garantir l'exactitude des données, les protocoles doivent adopter une stratégie multi-source de données en incorporant plusieurs oracles décentralisés, tels que Chainlink ou Band Protocol, pour agréger les données de divers échanges ou pools de liquidité. Cette approche atténue l'impact sur la sécurité globale du système si une source de données unique est manipulée.

2. Des agrégateurs de données décentralisés pour garantir la sécurité de la transmission des données

Analyse de cas : La défaillance de l'oracle hors chaîne de Synthetix a exposé les risques d'erreurs dans les sources de données hors chaîne. Dans cet incident, un prix incorrect du won coréen (KRW) a été signalé, permettant à un robot de trading d'exploiter l'erreur pour l'arbitrage. Si Synthetix avait utilisé un agrégateur de données décentralisé, d'autres sources de données décentralisées auraient pu corriger rapidement le problème, même si une source de données hors chaîne avait échoué.

Approche d'optimisation : À l'instar des améliorations apportées à Uniswap V3, l'utilisation d'agrégateurs de données décentralisés peut renforcer la sécurité de la transmission des données. En combinant des protocoles cryptographiques (tels que TLS) et la vérification des signatures, ainsi que des nœuds de relais décentralisés, les systèmes peuvent prévenir les attaques de l'homme du milieu et la falsification des données. Par exemple, dans l'oracle Chainlink, chaque source de données est validée par plusieurs nœuds indépendants et protégée par des techniques de chiffrement pour garantir l'intégrité et l'immutabilité des données transmises.

4. Conception modulaire de l'architecture d'application pour réduire les risques de défaillance ponctuelle

Analyse de cas: De nombreux incidents d'attaque révèlent des déficiences dans la conception modulaire des protocoles DeFi, qui manquent souvent de mécanismes de défense suffisants. En concevant et en construisant soigneusement des modules indépendants, il est possible d'empêcher les attaquants d'exploiter une seule vulnérabilité pour causer des dommages catastrophiques à l'ensemble du système. Par exemple, dans le cas de l'échec de l'oracle hors chaîne de Synthetix, si l'équipe de développement avait conçu préventivement un système d'alerte modulaire, elle aurait pu identifier et rectifier plus rapidement les données anormales.

Approche d'optimisation : Pour renforcer la résistance aux attaques, les développeurs peuvent adopter des architectures en couches lors du processus de développement et veiller à ce que chaque module (source de données, logique de validation, module de transmission) fonctionne de manière indépendante. Par exemple, comme dans Uniswap V3, stocker les informations de prix provenant de différentes pools de liquidité dans des pools d'observation distincts permet au protocole de comparer les prix entre plusieurs pools, réduisant ainsi le risque de manipulation dans une seule pool. Dans le développement pratique, des techniques telles que l'encapsulation d'interface et l'injection de dépendances peuvent séparer le module de validation des données de la logique des autres, garantissant la flexibilité et la maintenabilité du système.

5. Mécanismes de défense adaptatifs dans les smart contracts

Alors que la plupart des oracles s'appuient sur des mesures de défense statiques, les contrats intelligents peuvent adopter des stratégies de défense adaptatives pour contrer les méthodes d'attaque hautement dynamiques. Par exemple, en surveillant la fréquence des fluctuations de prix anormales, le système peut déterminer si une attaque est en cours et déclencher des mécanismes de validation ou de retour en arrière supplémentaires en réponse à de telles anomalies. Cette approche adaptative peut protéger automatiquement le système contre les pertes potentielles lors de manipulations soudaines de prix.

Application pratique : Certains protocoles DeFi mettent en œuvre des mécanismes d'alerte de seuil pour détecter des fluctuations de prix significatives en temps réel. Si la fluctuation de prix dépasse un seuil prédéfini, le système déclenche automatiquement des processus de validation supplémentaires ou des annulations pour prévenir l'escalade de la manipulation. Par exemple, le protocole Balancer utilise un seuil de déviation de prix; si un prix est détecté comme excessivement élevé ou bas, il interrompt certaines transactions jusqu'à confirmation supplémentaire de la validité du prix.

En s'appuyant sur les discussions d'optimisation de la conception et de l'application de l'oracle, nous pouvons explorer des solutions spécifiques dans les applications DeFi. Ensuite, nous présenterons le mécanisme de prix moyen pondéré dans Uniswap V2 et ses améliorations dans V3.

Cas d'optimisation de la sécurité dans les applications Oracle DeFi

La sécurité des oracles est une préoccupation centrale pour les protocoles DeFi. De nombreux protocoles DeFi ont introduit des innovations précieuses pour prévenir efficacement les attaques d'oracle. Uniswap, par exemple, a fourni de nouvelles idées pour la conception d'oracle grâce à ses optimisations dans la génération de prix on-chain et les mécanismes de défense. Une comparaison entre Uniswap V2 et V3 démontre comment les améliorations techniques peuvent améliorer les capacités anti-manipulation des oracles, offrant ainsi une voie claire pour la conception sécurisée de contrats intelligents.

TWAP sur Uniswap V2

Uniswap V2 a introduit l'oracle TWAP (Time-Weighted Average Price) pour la première fois, permettant aux développeurs on-chain d'accéder aux données de prix des échanges décentralisés (DEX). TWAP est un oracle on-chain qui puise ses données à partir des propres données de trading on-chain d'Uniswap sans dépendre de données off-chain.

Dans le UniswapV2Paircontrat, le_update()La fonction est la fonction privée principale chargée de mettre à jour les réserves et les accumulateurs de prix des paires de trading. Son objectif principal est d'utiliser l'accumulateur de prix pondéré dans le temps pour aider à prévenir les attaques des oracles.

L'idée principale de cette fonction est de limiter la capacité d'un attaquant à manipuler les prix à un instant donné en enregistrant les variations de prix pondérées dans le temps pour chaque bloc. Plus précisément, la fonction calcule la différence de temps (temps écoulé) entre l'heure actuelle et la dernière mise à jour, multiplie cette différence par le prix actuel de la paire de trading, puis ajoute le résultat aux accumulateurs de prix (price0CumulativeLastet prix1CumulativeLast). Cette accumulation enregistre le prix moyen pondéré dans le temps afin de lisser les éventuelles fluctuations de prix. Étant donné que le prix est cumulé sur une période, les attaquants devraient opérer en continu sur plusieurs blocs pour modifier de manière significative le prix, ce qui augmente le coût de manipulation.

De plus, la fonction met à jour les accumulateurs de prix uniquement si timeElapsedest supérieure à 0, ce qui signifie que le prix ne sera mis à jour qu'une fois par bloc. Cette conception limite la fréquence des opérations d'un attaquant dans un court laps de temps. Pour manipuler efficacement le prix, les attaquants devraient intervenir en continu sur plusieurs blocs plutôt que sur un seul bloc, réduisant ainsi davantage la probabilité de manipulation.

D'un point de vue sécurité, ce mécanisme est robuste. La fonction inclut des vérifications de débordement pour s'assurer que les valeurs maximales des réserves n'excèdent pas les limites du système, et les calculs de prix cumulatifs sont également protégés contre le débordement. Ces éléments de conception rendent la manipulation externe significativement plus difficile.

Cependant, la version V2 de l'oracle présente certaines limitations pratiques. Par exemple, le contrat officiel ne fournit que les dernières valeurs de prix cumulées, ce qui oblige les développeurs à enregistrer et récupérer des données historiques de prix, ce qui impose une barrière technique plus élevée. De plus, l'oracle V2 n'enregistre pas directement la profondeur de la paire de trading. La profondeur de la paire de trading est essentielle à la stabilité de l'oracle face aux attaques, une faible profondeur rendant plus facile la manipulation des prix.

Uniswap V3

Pour remédier aux limitations de son prédécesseur, Uniswap a amélioré la fonctionnalité de l'oracle dans sa version V3. Les contrats V3 ont conservé les valeurs de prix cumulatives dans le temps et ont ajouté la capacité de stocker des informations de prix historiques, prenant en charge jusqu'à 65 535 enregistrements. Cela a éliminé la nécessité pour les développeurs de stocker manuellement les données historiques.

De plus, l'oracle de la version V3 enregistre les valeurs de liquidité pondérées dans le temps pour différentes tranches de frais. Cela permet aux développeurs de sélectionner des pools de liquidité avec des volumes plus élevés comme sources de référence de prix, garantissant une plus grande précision des prix. Toute la logique liée à l'oracle est encapsulée dans la bibliothèque Oracle, permettant aux contrats d'enregistrer automatiquement les informations cumulatives sur les prix et la liquidité pour chaque transaction sans nécessiter de maintenance utilisateur externe.

Une autre amélioration remarquable est l'ajustement de la méthode de calcul des prix. Dans Uniswap V2, les calculs TWAP étaient basés sur la moyenne arithmétique, tandis que V3 adopte la moyenne géométrique. Comparée à la moyenne arithmétique, la moyenne géométrique offre une plus grande stabilité dans la mise en œuvre et est mieux adaptée aux environnements à forte volatilité des prix, réduisant ainsi davantage le risque de manipulation.

Tendances futures

Les attaquants d'Oracle comprennent des groupes organisés, des hackers indépendants et des éventuels initiés collaborant avec des parties externes. De telles attaques impliquent généralement une complexité technique modérée, nécessitant que les attaquants aient une compréhension fondamentale de la blockchain et des smart contracts ainsi que des compétences spécifiques pour exploiter les vulnérabilités. À mesure que les barrières techniques diminuent, la complexité des attaques d'oracle diminue, permettant à des hackers moins expérimentés sur le plan technique de participer.

Les attaques Oracle dépendent fortement de l'automatisation. La plupart des attaquants utilisent des outils automatisés pour analyser les données de la chaîne, identifiant rapidement et exploitant les vulnérabilités de sécurité telles que les fluctuations de prix ou les retards de données dans les oracles. Par exemple, les bots d'arbitrage et les scripts automatisés peuvent réagir aux changements de prix en quelques millisecondes, garantissant aux attaquants de réaliser des bénéfices avant que le marché ne s'ajuste. À mesure que les réseaux blockchain continuent de se décentraliser, ces méthodes automatisées deviennent de plus en plus efficaces, rendant les attaques Oracle plus précises et plus difficiles à détecter.

À l'avenir, la fiabilité des données des oracles et la résistance à la manipulation devraient s'améliorer grâce à l'adoption généralisée de mécanismes de tarification standardisés tels que le prix moyen pondéré par le temps (TWAP) et la validation de données provenant de plusieurs sources signées cryptographiquement. Bien que cela puisse réduire la faisabilité des attaques des oracles, de nouvelles menaces pourraient émerger, en particulier des méthodes sophistiquées combinant diverses techniques d'arbitrage pour contourner les contrôles de sécurité. Les développeurs DeFi doivent rester vigilants, car la sécurité des oracles dépendra de l'amélioration continue des mesures de protection des données décentralisées et de la défense proactive contre les vecteurs d'attaque émergents.

Conclusion

Cet article a exploré le rôle critique des oracles dans les systèmes DeFi et leurs vulnérabilités en matière de sécurité, en examinant les types d'oracles, les exemples de développement, les études de cas et les mesures préventives. L'analyse s'est concentrée sur deux domaines clés: les attaques d'oracle basées sur les prêts flash et les attaques aléatoires découlant des défaillances d'oracle. Grâce à cet examen, nous avons démontré l'importance fondamentale des oracles dans l'architecture de sécurité DeFi et leur besoin de résistance à la manipulation tout en fournissant des méthodes pratiques pour prévenir les attaques d'oracle.

Avertissement : Le contenu de cet article est uniquement destiné à des fins de référence et à l'échange de connaissances sur les attaques oracle. Il ne constitue pas un guide pour des opérations réelles ou des cas d'instruction.