Oracle : Les yeux de la DeFi, mais aussi sa faiblesse

Rédigé par : Zhang Qianwen

En novembre 2020, une personne, avec de l’argent emprunté, a emporté en 15 secondes près de 1 million de dollars hors d’un protocole DeFi.

Elle a d’abord emprunté une grande quantité de ETH via un prêt flash, puis a concentré ses achats de sETH dans un pool de liquidité extrêmement faible, faisant grimper brutalement le prix en quelques secondes seulement.

Ensuite, elle a déposé ces sETH comme garantie dans le protocole bZx. Ce que le protocole « voit », c’est le prix qui vient d’être artificiellement tiré à ce même instant ; il considère alors que la valeur de ces sETH est extrêmement élevée, et libère, conformément aux règles, des prêts WBTC très au-delà de la valeur réelle.

Après avoir obtenu les WBTC, l’attaquant a remboursé rapidement le prêt flash, emportant avec lui un énorme différentiel, puis est parti tranquillement.

L’ensemble du processus n’a impliqué aucune intrusion de pirate, aucun bug dans le code, et aucun abus de droits. Le contrat a exécuté chaque étape strictement selon les règles. Le seul problème, c’est que :

le monde qu’il « voit » est faux.

C’est l’une des limites les plus fondamentales de DeFi : les contrats on-chain, en essence, constituent un système qui ne peut pas voir le monde réel.

01 Les contrats on-chain sont un « aveugle »

Les contrats intelligents vivent dans un monde fermé.

Ils peuvent voir tout ce qui se passe sur la chaîne : qui a transféré de l’argent à qui, combien, quelle adresse détient combien de tokens, quelle transaction a été incluse dans un bloc à quel moment — toutes ces informations, ils peuvent les lire, et elles sont absolument exactes.

Mais le monde hors chaîne, ils ne peuvent absolument pas le voir : quel est le prix de l’ETH aujourd’hui ? le Bitcoin a-t-il franchi de nouveaux sommets ? un stablecoin a-t-il perdu son ancrage ? la bourse de New York est-elle montée ou baissée aujourd’hui ? le contrat n’en sait rien.

Dans le prêt-emprunt DeFi, c’est une contradiction fatale.

La liquidation dépend du prix actuel des actifs en garantie ; mais le contrat ne peut pas voir le prix par lui-même, il faut que quelqu’un le lui indique.

C’est la raison d’être des oracles : ce sont les yeux des contrats on-chain, chargés d’apporter des informations réelles hors chaîne sur la chaîne, pour que le contrat puisse les lire et les utiliser. Mais un problème en découle immédiatement :

qui peut garantir que cette information est vraie ?

02 Oracle : le messager du monde on-chain

Un oracle est, fondamentalement, une infrastructure de transmission d’informations : les données du monde réel (prix, taux d’intérêt, résultats d’événements, etc.) sont écrites dans la blockchain sous une forme lisible par les contrats.

Ce concept paraît simple, mais le défi côté ingénierie tient au fait que le principe de conception central d’une blockchain est : « ne faire confiance à aucune entrée externe ». Seules comptent les données vérifiables sur la chaîne. Et ce qu’apportent les oracles, c’est précisément les données hors chaîne — elles se trouvent naturellement en dehors de ce cadre de confiance.

Pour résoudre ce problème, deux grandes approches dominantes se sont formées sur le marché.

La première consiste à utiliser le prix on-chain, en lisant directement les prix des transactions sur une bourse décentralisée (DEX). Le cas le plus typique est le prix moyen pondéré dans le temps (TWAP) d’Uniswap : on ne prend pas le prix instantané à un moment donné, mais la moyenne sur une période passée, en diluant les fluctuations de prix à court terme grâce au facteur temps.

La deuxième approche consiste en un réseau d’oracles décentralisés, représenté par Chainlink. Plusieurs nœuds de données indépendants récupèrent chacun les prix via des canaux différents ; après agrégation, ils envoient sur la chaîne la médiane, et aucun nœud ne peut, à lui seul, décider du résultat final.

Les deux solutions ont leurs compromis, mais elles tentent toutes de répondre à la même question : comment faire en sorte que les contrats on-chain fassent confiance à un chiffre provenant d’un oracle hors chaîne ?

03 Pourquoi ne pas utiliser directement le prix en temps réel ?

La plupart des gens, en découvrant les oracles pour la première fois, ont une intuition : puisque le prix provient du marché, pourquoi ne pas lire directement le prix en temps réel des bourses ?

Le problème, c’est que : le prix en temps réel n’est pas égal au prix réel.

Sur des marchés où la liquidité est suffisante et où les transactions sont actives, les deux sont généralement assez proches ; mais dans des pools où la liquidité est faible et la profondeur insuffisante, dès lors qu’il y a assez de fonds, le prix peut être artificiellement poussé à bien plus haut que le niveau du marché réel en très peu de temps.

Et un contrat intelligent ne peut pas déterminer si ce prix s’est formé naturellement ou s’il a été manipulé de manière intentionnelle. Il ne peut que lire ce nombre et exécuter ses règles — autoriser l’emprunteur à emprunter plus de fonds. Lorsque le prix retombe, la valeur réelle de la garantie ne suffit même pas à couvrir le prêt ; le protocole se retrouve alors avec des créances douteuses.

C’est précisément la raison pour laquelle l’événement d’attaque du protocole bZx mentionné au début de l’article se produit, et c’est aussi le coût de l’utilisation du prix en temps réel : l’oracle traite des « nombres qui peuvent être manipulés temporairement » comme s’ils étaient la réalité.

04 La solution de Chainlink : décentraliser le prix

Si un système ne dépend que d’une seule source de données, alors dès que cette source fait une erreur ou est manipulée, l’ensemble du protocole sera entraîné dans la mauvaise direction. Le moyen le plus direct de réduire ce risque n’est pas de faire confiance à une personne « plus forte », mais de faire rapporter le nombre par plusieurs nœuds indépendants, puis d’extraire un résultat relativement robuste.

La solution de Chainlink adopte exactement cette idée : plusieurs nœuds de données indépendants récupèrent le prix depuis des sources de données différentes, chacun le remonte ; le système prend la médiane comme résultat final. Ainsi, même si un nœud individuel fait une erreur, ou est influencé par un attaquant, cela ne suffit pas à faire pencher le prix final ; et pour qu’un attaquant contrôle simultanément plus de la moitié des nœuds, il faudrait accomplir une tâche presque impossible d’un point de vue économique.

Ce mécanisme permet de réduire efficacement le problème de la manipulation par point unique.

Mais il introduit aussi un nouveau coût : un délai de mise à jour.

Le prix on-chain n’est pas synchronisé en temps réel : les nœuds collectent des données, parviennent à un consensus, puis les écrivent dans la blockchain — ce processus prend du temps. Quand le marché fluctue normalement, ce délai n’a pas beaucoup d’importance. Mais lorsque la volatilité du marché est forte, le prix de l’oracle pourrait ne pas suivre les changements du prix réel.

C’est précisément pour cela que, dans Pourquoi l’emprunt DeFi doit-il être sur-garanti ? il est indiqué que les protocoles d’emprunt DeFi doivent prévoir un coussin de sur-garantie : il ne sert pas seulement à faire face aux fluctuations de prix elles-mêmes, mais aussi à ce que, pendant le laps de temps où l’oracle n’a pas encore eu le temps de se mettre à jour, le système dispose toujours d’une marge de sécurité suffisante pour déclencher la liquidation.

05 Attaque d’oracle : la crise de confiance la plus coûteuse

Le problème des oracles n’a pas totalement disparu avec l’arrivée de Chainlink.

Dans l’histoire de DeFi, les vulnérabilités liées aux oracles font partie des catégories d’attaques ayant causé les pertes les plus lourdes. Entre 2021 et 2023, rien que les attaques d’oracle pour lesquelles on dispose de preuves documentées, ont entraîné des pertes cumulées de plus de plusieurs centaines de millions de dollars.

Ces pertes partagent une caractéristique commune : l’attaquant n’a pas besoin de trouver une faille dans le code. Il lui suffit de repérer l’écart entre le prix de l’oracle et le prix réel du marché, puis d’utiliser des fonds pour élargir cet écart, afin que le contrat exécute une opération en se basant sur un prix déformé, opération qui est avantageuse pour lui. C’est un risque plus difficile à défendre que les vulnérabilités de code — parce que vous ne pouvez pas écrire, dans le code, une règle pour juger « ce prix est-il réel ».

Le problème des oracles n’est pas, en essence, une faille d’un composant en particulier ; c’est une forme d’arbitrage :

plus vous utilisez de sources de données pour lutter contre la manipulation, plus vous devez accepter un délai plus élevé ;

plus vous cherchez un prix plus proche du temps réel, plus vous devez assumer le risque d’être manipulé temporairement.

Il n’existe pas de solution parfaite à cet arbitrage.

Et c’est justement pour cela que la présence des oracles révèle une réalité plus profonde de DeFi : les contrats on-chain peuvent être absolument transparents, absolument exécutoires, mais à condition que les informations d’entrée sur lesquelles ils s’appuient soient réelles. Dès que ces entrées sont faussées, même un code parfait ne fera que des jugements et des exécutions erronés, mais de manière plus efficace.