Votre position à effet de levier a failli vous coûter tout votre capital la nuit dernière, et le vrai coupable n’est en réalité pas la volatilité du marché, mais le tueur invisible derrière le système DeFi.

Ce genre d’histoires, nous en avons vu beaucoup : le marché est très calme, voire sans fluctuations anormales, mais la position que vous avez prise sur un protocole de prêt ou un dérivé est soudainement liquidée en chaîne. Le compte est vidé en un instant, et il est souvent trop tard lorsque vous vous en rendez compte.

En y regardant de plus près, on découvre que le principal responsable est souvent un problème avec la feed d’oracle. Une donnée erronée peut déclencher une réaction en chaîne sur toute la blockchain. Ce n’est pas un événement à faible probabilité, mais une vieille habitude récurrente dans le monde DeFi.

Où se trouve le problème ? Fondamentalement, la blockchain ne peut pas se connecter directement aux données du monde réel. Il faut une "passerelle" — c’est-à-dire un oracle — pour transporter sur la chaîne des informations comme les prix, la météo, les taux de change, etc. Le problème, c’est que cette passerelle est trop fragile :

Les données peuvent être retardées ou falsifiées

Un prix extrême peut instantanément déclencher une tempête de liquidations

Les nœuds centralisés peuvent mal faire ou un point de défaillance unique peut paralyser tout le système

Certains ont pensé à une autre voie. Plutôt que de faire tous les calculs en chaîne (ce qui est lent et coûteux), il serait préférable de faire la collecte de données et les calculs complexes hors chaîne, puis de ne mettre en chaîne que le résultat pour vérification et confirmation. Cela ressemble à une "décision judiciaire" — la collecte et l’analyse des preuves se font en dehors du tribunal, et le juge tranche uniquement sur la base de preuves suffisantes.

Cette approche de validation en couches présente plusieurs avantages : la logique de calcul peut être adaptée de manière flexible, sans compromettre la sécurité. Les protocoles de dérivés peuvent nécessiter des calculs complexes de volatilité, les protocoles d’assurance peuvent avoir besoin de données météorologiques — chaque scénario a ses besoins spécifiques, mais tout peut être géré dans ce cadre.

Est-ce que cette approche peut complètement résoudre le problème des oracles ? Il faut encore voir lors des tests en situation réelle. Mais elle indique au moins une direction : plutôt que de subir passivement le risque, il vaut mieux concevoir activement une architecture de données plus résiliente.