Un contrat qui liquide une position a besoin de connaître un prix, et la chaîne sur laquelle il tourne n'a aucun moyen d'en trouver un. Tout ce qui a mal tourné dans cette partie de la pile découle de cette seule limite, et la comprendre explique une famille de pertes qui autrement ressemblent à un marché se comportant de façon impossible.
Une blockchain est déterministe par conception : chaque participant qui fait tourner le logiciel doit arriver exactement au même résultat à partir des mêmes entrées, sinon le consensus échoue. Cette exigence interdit de demander quoi que ce soit au monde extérieur, parce que deux participants interrogeant une source externe à des instants légèrement différents obtiendraient des réponses différentes et seraient en désaccord sur l'état du registre.
Donc un contrat qui a besoin de savoir ce que vaut un actif ne peut pas aller le chercher. L'information doit être placée sur la chaîne par quelqu'un, dans une transaction, en devenant une donnée du registre comme une autre. À partir de cet instant le contrat peut la lire de façon déterministe, et tout le monde s'accorde, parce que tous lisent le même nombre enregistré au lieu de demander chacun au monde séparément.
C'est tout ce qu'est un oracle : un mécanisme pour écrire une information extérieure sur une chaîne afin que des contrats puissent agir dessus. Ce n'est pas une fenêtre magique sur le réel. C'est quelqu'un qui saisit un nombre, avec des règles sur qui a le droit de saisir et sur ce qui se passe s'il saisit le mauvais.
Les contrats ne lisent pas le marché. Ils lisent un nombre que quelqu'un a écrit, et toute question sur le risque d'oracle est une question sur qui l'a écrit et comment.
Les différences se ramènent à la même question que pour les ponts : combien de parties devraient se tromper ou mentir en même temps pour que le nombre enregistré soit faux.
Une partie observe les prix et les écrit. C'est bon marché, rapide, et sa précision est exactement celle de cette partie. Cette conception existe encore en production et elle concentre l'intégrité entière de tout ce qui est en aval dans la gestion des clés d'une seule entité et dans le flux de données d'une seule entité.
De nombreuses parties indépendantes rapportent chacune, et le contrat prend une médiane ou une statistique robuste similaire. Un rapporteur unique faux ou malveillant est écarté par l'agrégation, ce qui est une vraie amélioration, et la faiblesse de la conception se déplace vers la question de savoir si les rapporteurs sont réellement indépendants. Des publieurs qui lisent tous la même poignée de sources sont un seul publieur portant plusieurs manteaux, et l'agrégation ne peut pas le détecter.
Plutôt que d'importer un prix extérieur, certains systèmes en calculent un à partir de transactions ayant eu lieu sur la chaîne elle-même, qui sont visibles et n'exigent aucun rapporteur. Cela retire entièrement l'humain et remplace le problème par un autre : le prix reflète désormais un marché précis plutôt que le marché, et ce marché peut être assez petit pour être déplacé.
Même un oracle bien construit rapporte quelque chose de légèrement différent de ce que vous verriez à l'écran, et les écarts sont structurels plutôt que des erreurs. Il se met à jour par intervalles plutôt qu'en continu, donc entre deux mises à jour le prix enregistré est périmé par construction. Il agrège plusieurs sources, donc c'est un résumé de plusieurs marchés plutôt que le prix de l'un d'eux. Et il applique en général un lissage, donc un vrai mouvement brusque arrive atténué.
Chacun de ces choix se défend et chacun a un coût. Des mises à jour fréquentes coûtent des frais de transaction à chaque fois, donc l'intervalle est une décision économique plutôt qu'une limite technique. L'agrégation protège contre une mauvaise source et garantit que le nombre ne coïncidera jamais exactement avec la place que vous regardez. Le lissage empêche la manipulation par de brèves pointes et, par exactement le même mécanisme, retarde la reconnaissance des vraies.
La conséquence pratique est que toute position dont le sort dépend d'un oracle est exposée à la configuration de cet oracle autant qu'au marché. Deux positions identiques sur deux plateformes peuvent survivre et être liquidées le même jour, non parce que le marché s'est contredit mais parce que les deux oracles étaient configurés différemment.
Regrouper les incidents fait apparaître un petit nombre de formes répétées, et aucune n'a exigé de casser la moindre cryptographie.
Si un oracle dérive son prix d'un marché mince par rapport à la valeur des positions qui en dépendent, un attaquant peut emprunter du capital, pousser ce marché très loin pendant quelques secondes, et profiter des contrats qui agissent sur le nombre déformé. La manipulation est coûteuse et elle est bornée par la profondeur du marché poussé, ce qui explique que les oracles qui lisent des marchés minces soient les vulnérables.
Entre deux mises à jour, le prix enregistré est connu pour être périmé, et si le vrai marché a bougé substantiellement dans cette fenêtre, n'importe qui peut traiter contre le contrat à l'ancien prix. Ce n'est pas de la manipulation, c'est de l'arbitrage contre un délai connu, et cela a vidé de la valeur substantielle de systèmes dont la fréquence de mise à jour avait été réglée pour le coût plutôt que pour la sûreté.
Là où une agrégation a peu d'entrées réellement indépendantes, désactiver ou dégrader une ou deux d'entre elles peut déplacer l'agrégat assez pour compter, sans qu'aucun des rapporteurs restants ne fasse quoi que ce soit de mal.
La défense standard contre la manipulation brève est de rapporter une moyenne sur une fenêtre plutôt que la dernière valeur. Pousser un prix pendant quelques secondes ne déplace alors presque pas un chiffre moyenné sur une demi-heure, et le coût d'une manipulation croît avec la durée exigée, ce qui rend l'attaque non rentable dans la plupart des cas.
Le coût est symétrique et on ne le mentionne pas toujours. Un prix moyenné retarde un vrai mouvement par construction, ce qui veut dire que l'oracle annonce qu'un actif vaut plus qu'il ne vaut pendant une vraie baisse. Des positions qui auraient dû être liquidées ne le sont pas, elles continuent de chuter, et le système peut se retrouver à détenir un collatéral qui vaut moins que la dette en face. La protection contre les faux mouvements est exactement le même mécanisme que le retard sur les vrais.
Quel échec un système préfère est un choix de conception sans réponse correcte. Une fenêtre courte résiste au retard et invite la manipulation ; une longue résiste à la manipulation et invite la mauvaise dette pendant les vrais krachs. Les deux ont produit des pertes, et le choix d'un système est en général documenté, rarement lu, et directement pertinent pour qui y détient une position à levier.
La moyenne bat une fausse pointe et retarde une vraie, par le même mécanisme. Aucun réglage ne les distingue.
La plupart des oracles en production se mettent à jour sur deux déclencheurs. Un battement force une mise à jour après un intervalle maximal quoi qu'il se soit passé, garantissant que le prix n'est jamais plus vieux que cela. Un seuil d'écart force une mise à jour anticipée quand le prix a bougé de plus d'un montant fixé depuis la précédente, de sorte que les marchés rapides sont mis à jour plus souvent que les calmes.
Les deux paramètres sont publics et les deux méritent d'être connus pour toute plateforme où vous détenez du levier. Un battement long avec un seuil d'écart large signifie que le prix enregistré peut rester inchangé pendant un mouvement substantiel, et toute logique de liquidation qui le lit agira en retard. Un battement court coûte plus cher en frais et est en général réservé aux actifs qui portent le plus de valeur.
C'est aussi pourquoi le même actif peut avoir un comportement d'oracle différent sur des plateformes différentes même quand le flux sous-jacent est le même. Le flux publie ; la plateforme choisit comment elle le consomme, et ce choix détermine ce que votre position vit pendant les minutes qui comptent.
La plainte confuse la plus fréquente en trading à levier est qu'une position a été fermée à un niveau que le graphique n'a jamais atteint. Le graphique montre une place ; l'oracle rapporte un autre nombre dérivé de plusieurs, peut-être moyenné, peut-être périmé, et le moteur de liquidation agit sur l'oracle plutôt que sur le graphique que vous regardiez.
Il y a un second contributeur, moins évident. De nombreuses plateformes utilisent délibérément un prix lissé ou indiciel pour les liquidations plutôt que la dernière transaction de leur propre carnet, précisément pour qu'une brève pointe sur leur propre place ne déclenche pas une vague de fermetures. C'est un choix protecteur et il produit la même expérience : votre position a réagi à un nombre dont vous n'aviez aucun affichage.
Le remède n'est pas d'en discuter mais de regarder le bon nombre. Toute plateforme qui offre du levier publie quel prix son moteur de liquidation utilise, et l'affiche fréquemment à côté de la dernière transaction. Le trader qui règle son risque contre le prix traité pendant que le moteur en lit un autre gère une distance qui n'est pas celle qui est mesurée.
Quatre choses, toutes documentées et aucune n'exigeant de compétence technique. Quel prix le moteur de liquidation lit, et s'il est affiché quelque part où vous pouvez le voir. Comment ce prix est construit, c'est-à-dire combien de sources et s'il est moyenné sur une fenêtre. À quelle fréquence il se met à jour, par le battement et le seuil d'écart. Et sur les actifs que vous traitez vraiment, la profondeur des marchés qui l'alimentent, puisqu'un oracle qui lit des marchés minces est celui qui est exposé à la manipulation.
Rien de tout cela n'empêche quoi que ce soit à soi seul, et cela convertit toute une famille de surprises en paramètre connu. Un trader qui sait que sa plateforme liquide sur une moyenne à trente minutes comprend à l'avance pourquoi une reprise rapide ne sauvera pas une position, et peut dimensionner en conséquence. Un trader qui l'ignore vivra le même événement comme un marché se comportant de façon impossible.
Parce qu'une blockchain doit être déterministe : chaque participant doit atteindre le même résultat à partir des mêmes entrées. Deux participants interrogeant une source externe à des instants légèrement différents obtiendraient des réponses différentes et seraient en désaccord sur le registre. Une donnée externe doit donc d'abord être écrite sur la chaîne, dans une transaction, avant qu'un contrat puisse la lire.
Un mécanisme pour écrire une information extérieure sur une chaîne afin que des contrats puissent agir dessus de façon déterministe. Ce n'est pas une fenêtre sur le réel ; c'est une règle sur qui peut publier un nombre et sur ce qui se passe s'il en publie un faux. Toute question sur le risque d'oracle se ramène à ces deux choses.
Parce que le moteur de liquidation lit l'oracle, pas le graphique. Ce prix est en général agrégé sur plusieurs places, souvent moyenné sur une fenêtre, et mis à jour par intervalles. Beaucoup de plateformes utilisent un indice lissé délibérément, pour qu'une brève pointe sur leur propre carnet ne déclenche pas une vague de fermetures.
Une moyenne sur une fenêtre plutôt que la dernière valeur. Elle rend la manipulation brève non rentable, parce que pousser un prix quelques secondes ne déplace presque pas une moyenne d'une demi-heure. Le coût est qu'elle retarde les vrais mouvements par exactement le même mécanisme, ce qui peut laisser des positions non liquidées pendant une vraie baisse.
Généralement en déplaçant le marché qu'il lit. Si le prix est dérivé d'une place mince par rapport aux positions qui en dépendent, un attaquant peut emprunter du capital, pousser brièvement cette place, et profiter des contrats qui agissent sur le nombre déformé. L'attaque est bornée par la profondeur du marché poussé.
Les deux déclencheurs qui provoquent une mise à jour. Le battement en force une après un intervalle maximal quel que soit le mouvement, donc le prix n'est jamais plus vieux que cela. Le seuil d'écart en force une anticipée quand le prix a bougé de plus d'un montant fixé. Les deux sont publics et les deux déterminent avec quel retard un moteur de liquidation peut agir.
Pas nécessairement, et même là où le flux sous-jacent est partagé, chaque plateforme choisit comment elle le consomme. Deux positions identiques sur deux plateformes peuvent donc se comporter différemment le même jour, parce que c'est la configuration et non le marché qui a décidé du résultat.
Quel prix le moteur de liquidation lit et s'il est affiché, comment ce prix est construit et s'il est moyenné, à quelle fréquence il se met à jour, et la profondeur des marchés qui l'alimentent. Les quatre sont documentés, et les connaître convertit une famille de surprises en un paramètre contre lequel on peut dimensionner.