Aller au contenu
Financial Context Wiki

Oracle blockchain

Un oracle blockchain fournit aux contrats des affirmations authentifiées sur des données qu'ils ne peuvent pas déduire de l'état déterministe de la chaîne ; son utilisation sûre dépend de tout le parcours entre source, rapport, transport, vérification et consommateur.

Mis à jour

À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.

Réponse directe

Un oracle blockchain est un système qui fournit à un contrat une affirmation authentifiée sur des données que la transition déterministe de l’état de la chaîne ne peut pas déduire seule. Un flux de prix peut publier une référence de marché, un oracle pull peut vérifier une mise à jour signée relayée par l’utilisateur et un oracle optimiste peut accepter une affirmation assortie d’une caution si elle n’est pas contestée. L’aléa vérifiable et les messages interchaînes sont des systèmes apparentés d’entrée externe, mais leurs affirmations et modèles de sécurité ne sont pas interchangeables avec ceux des flux de prix.

L’inscription d’une valeur onchain prouve qu’une transaction, une signature, un quorum, une preuve ou l’issue d’un litige a respecté des règles définies. Elle ne prouve pas cryptographiquement qu’un marché externe, un phénomène météorologique ou un jugement humain est objectivement vrai. Le parcours de confiance complet comprend le phénomène observé, les sources et places de marché, les éditeurs, l’agrégation, l’authentification du rapport, le transport, le proxy ou vérificateur onchain, la validation du consommateur et l’action économique qui déplace la valeur.

La décentralisation doit être évaluée séparément à chaque niveau. De nombreux signataires peuvent partager la même API, plateforme d’échange, infrastructure cloud, entité opérationnelle ou administration. Une médiane signée et récente peut néanmoins employer la mauvaise paire ou le mauvais nombre de décimales, refléter un marché illiquide ou être inadaptée à la taille de l’opération du consommateur. Celui-ci reste responsable de l’identité, des unités, du statut, des horodatages, de la disponibilité L2, des limites d’exposition, du comportement de secours et du rétablissement.

Fonctionnement

  1. Fixez la chaîne et le bloc, le contrat consommateur et l’action, l’adresse exacte du flux ou du proxy et l’identifiant du flux, la version de l’implémentation, la paire base/cotation, les décimales ou l’exposant, les horaires de marché et la valeur exposée.
  2. Retracez tout le parcours de confiance depuis le phénomène et les places de marché jusqu’aux éditeurs, à l’agrégation des sources, à l’agrégation des signataires ou du quorum, au transport, à la vérification onchain, aux contrôles du proxy et à la logique du consommateur ; testez séparément l’indépendance des sources, opérateurs, infrastructures et administrateurs.
  3. Décodez l’interface et le rapport déployés. Validez l’identité du flux, la signature ou la preuve et son domaine, la séquence ou le tour, la valeur signée, le statut ou l’intervalle de confiance, l’horodatage source, l’heure de mise à jour onchain, le comportement en cas de rejeu et de revert ainsi que l’état de mise à niveau.
  4. Normalisez les unités une seule fois et appliquez des contrôles explicites de plage, de signe et d’horodatage. Distinguez l’observation ou publication à la source, la création du rapport, l’inclusion sur la chaîne source, la finalité du relais, la mise à jour sur la chaîne cible et l’heure du bloc consommateur.
  5. Appliquez des règles propres à chaque action pour maxAge, l’écart, la confiance et la comparaison entre sources. Sur les déploiements L2 pris en charge, contrôlez séparément le statut du séquenceur et le délai de grâce après son rétablissement ; pour les valeurs composées, faites dépendre la fraîcheur de la plus ancienne dépendance requise.
  6. Comparez la référence à la profondeur de marché exécutable et estimez le coût de manipulation ou de corruption par rapport à l’exposition du consommateur liée à l’emprunt, l’émission, la liquidation, la négociation ou le règlement. Traitez le prix spot et la construction du TWAP d’un AMM comme propres au pool et à sa version.
  7. Définissez des états normal, dégradé, suspendu et de rétablissement par action ; préservez si possible le remboursement sûr des dettes ou l’ajout de garantie, surveillez les sources et la configuration, testez les rapports absents, périmés, erronés et manipulés, puis rapprochez tous les soldes et actions touchés après le rétablissement.

Push et pull décrivent des modes de livraison, pas un modèle universel de paiement ou de confiance. Un éditeur peut créer un rapport signé qu’un utilisateur quelconque relaie en acquittant les frais de mise à jour. Les paramètres de heartbeat et d’écart peuvent déclencher une publication, mais ne garantissent ni sa livraison ni la limite de fraîcheur du consommateur. Une source de secours ou la dernière valeur valide constitue un mode contrôlé de dégradation dont la direction, les unités, l’âge, l’indépendance et les actions autorisées doivent être validés à nouveau.

Exemples détaillés

  • Seuil de liquidation. Une position comporte 10 ETH de garantie, un prix d’oracle de 3,000 USD/ETH, une dette de 18,000 USD et un seuil de liquidation de 75%. La garantie vaut 30,000 USD, le LTV est de 60% et healthFactor = 10 * 3,000 * 0.75 / 18,000 = 1.25. Le prix de déclenchement est 18,000 / (10 * 0.75) = 2,400 USD/ETH. À 2,300 USD/ETH, le facteur de santé est de 0.9583333333 et dette/garantie de 78.2608695652% : la position est liquidable, même si la garantie nominale de 23,000 USD dépasse encore la dette avant prime, frais et effets d’exécution.
  • Erreur d’unité. Une réponse brute de 250,000,000,000 avec 8 decimals signifie 2,500 USD. La diviser par 10^18 produit au contraire 0.00000025 USD, soit une sous-évaluation d’un facteur 10^10. Une signature valide et un horodatage récent ne corrigent pas une erreur d’unité du consommateur.
  • Choix de l’agrégation. Les observations [99, 100, 100, 101, 160] ont une médiane de 100 et une moyenne arithmétique de 112, soit un écart de 12% par rapport à la médiane. Dans cet exemple pédagogique, la médiane résiste à une valeur aberrante élevée ; mais si les cinq rapporteurs dépendent d’une API compromise et publient 130, la médiane vaut également 130.
  • Fraîcheur par action. À consumerClock = 1,800,000,000, un rapport dont sourceTimestamp = 1,799,998,200 présente age = 1,800 seconds. Un nouvel emprunt avec maxAge = 900 seconds le refuse avec 900 seconds de dépassement ; un parcours de remboursement avec maxAge = 3,600 seconds l’accepte avec 1,800 seconds de marge. Le même rapport peut être dangereux pour accroître l’exposition, mais acceptable pour la réduire.

Risques

  • Chaîne, déploiement, implémentation ou environnement réseau incorrect.
  • Proxy, agrégateur, identifiant du flux, actif ou version du contrat incorrect.
  • Sens base/cotation inversé ou dénomination incohérente.
  • Incompatibilité de décimales, d’exposant, de virgule fixe, de signe, d’arrondi ou d’unité.
  • Acceptation d’une réponse nulle, négative, hors domaine, en dépassement ou tronquée.
  • Acceptation d’un horodatage absent, nul, futur, reconduit ou mal identifié.
  • Limite de fraîcheur du consommateur trop permissive pour l’actif et l’action.
  • Limite trop stricte causant un déni de service ou empêchant la réduction du risque.
  • Configuration de heartbeat ou d’écart traitée comme une garantie de niveau de service.
  • Clôture du marché, opération sur titre, perte d’ancrage, indisponibilité d’une place ou sémantique de reconduction ignorée.
  • Plusieurs éditeurs partagent une API, une plateforme, un cloud, un opérateur, un chemin de clés ou une méthodologie.
  • Défaillance du seuil de signataires, du quorum, de la conservation des clés, de l’authentification, du domaine ou de la protection contre le rejeu.
  • Règles d’agrégation, de pondération, de valeurs aberrantes, de confiance ou de sélection des sources inadaptées.
  • Liquidité de la source faible, artificielle, fragmentée, périmée ou manipulable au montant protégé.
  • Manipulation du spot ou d’un TWAP court, contrôle multibloc, ordonnancement, censure ou MEV modifient l’entrée.
  • Éditeur, relais, gas, congestion, réorganisation ou panne de chaîne empêchent une livraison ponctuelle.
  • Statut du séquenceur L2, délai de grâce, horloge du relais interchaînes ou dépendance de finalité sont omis.
  • Proxy, administrateur, ensemble de signataires, configuration, migration, suspension ou retrait du flux changent sans être détectés.
  • La source de secours est périmée, corrélée, d’une autre échelle ou circulaire, ou s’active par un fail-open dangereux ou un fail-closed indiscriminé.
  • L’exposition dépasse le coût de manipulation ou de corruption tandis que surveillance, plafonds, suspension, rétablissement, liquidation et rapprochement des créances douteuses échouent.

Idées reçues

  • « Un oracle prédit l’avenir. » La plupart authentifient des observations, rapports, preuves ou affirmations résolues portant sur un objet et un moment définis.
  • « Des données signées ou onchain sont donc objectivement vraies. » L’authentification et le consensus prouvent le respect des règles, pas la justesse économique du fait externe.
  • « Plus de nœuds signifie automatiquement une décentralisation indépendante. » Sources, opérateurs, infrastructure, clés et gouvernance peuvent rester corrélés.
  • « La dernière valeur récente est un prix équitable et exécutable. » La fraîcheur n’établit ni le sens, ni les unités, ni la confiance, ni la liquidité, ni la profondeur exécutable.
  • « Un fournisseur réputé supprime le risque d’intégration du consommateur. » L’application reste responsable de l’identité du déploiement, du décodage, de la fraîcheur, des contrôles L2, de l’exposition, des modes de défaillance et du rétablissement.

Sujets connexes

Sources

Navigation

Rechercher dans le wiki...