Oracles, composabilité et risque de contrat

Source maître EN · P11-L07 · 30 minutes estimées · needs_review

Étude formative hors ligne. Aucune connexion à un portefeuille, aucun fonds réel, aucune clé privée, aucune signature, aucune négociation en direct ni donnée personnelle de portefeuille. Les visuels sont des spécifications ; il ne s’agit ni de contenu à l’exécution ni d’une certification.

Un contrat peut suivre exactement son code tout en consommant des entrées périmées, incompatibles ou économiquement fragiles.

Lire la signification du flux

Les flux agrègent des entrées et publient des mises à jour ; consommateurs, proxy et agrégateur sont des dépendances distinctes [ORACLE]. Noter paire d’actifs, réseau, décimales, heure de mise à jour, round et méthode des sources. Un nombre de flux n’est pas une valorisation infaillible ; un proxy peut introduire des dépendances de mise à niveau.

Appliquer le contrôle déclaré du consommateur

Notre consommateur fictif accepte un âge≤60 secondes avec paire et décimales correctes. À observationT1000, dernière mise à jourT900 donne âge100 et échoue au contrôle de fraîcheur. Un heartbeat fictif120 ne remplace pas la règle de60 secondes du consommateur. Les mises à jour réelles peuvent suivre des conditions d’écart et de heartbeat et subir le retard du réseau ; ce ne sont pas des flux continus de ticks.

Séparer prix spot du pool et historique de référence

Un rapport spot des réserves peut changer fortement avec un swap local. Le livre blanc v2 traite des observations de prix cumulées pondérées par le temps et du compromis fraîcheur/manipulation [V2]. Un TWAP est une méthode échantillonnée, pas une preuve contre toute manipulation ou marché périmé. Plusieurs flux peuvent partager des fournisseurs ; la redondance apparente n’implique pas l’indépendance.

Retracer la propagation des défaillances

La chaîne originale est actif enveloppé→contrat de remboursement→oracle→seuil de prêt→pool de sortie de liquidation. Pour chaque lien, demander quelle conversion ou hypothèse est utilisée. Une panne de remboursement peut miner le sens de l’oracle même si les mises à jour continuent. Portée, version du code et date d’un audit comptent ; l’audit ne garantit pas la sécurité. L’exercice hors ligne cartographie des conditions, sans attaque exécutable ni interaction de contrat.

• Fraîcheur : âge de la dernière observation fournie selon une règle du consommateur.
• Heartbeat : intervalle déclenchant une mise à jour, pas un flux continu.
• Composabilité : la sortie d’un composant devient l’entrée d’un autre.
• TWAP : estimation de prix pondérée par le temps avec fenêtre déclarée.

ILLUSTRATIVE consommateurT1000,flux mis à jourT900,heartbeat120,maxAge60 du consommateur,paire correcteSIM-X/SIM-Y,décimales2. Réponse brute12345 signifie123.45 Y/X. Route : wrappedX→redeemerR→feedF→lenderL→exitPoolE. Aucun contrat ni horodatage réel.

Carte de dépendances de type graphe de portefeuilles, liens explicitement techniques sans attribution d’identité/financement ; panneau de métadonnées du flux, âge100>60, conversion de réponse brute et branche de remboursement défaillant.

Échec de fraîcheur, conversion décimale et route de dépendances stipulée des données.

Configuration réelle du flux, indépendance des fournisseurs, remboursement, efficacité de l’audit ou sécurité du protocole.

• OBSERVED : FIX-P11-L07 donne mise à jourT900 et contrôleT1000.
• INFERRED : âge100 échoue à la règle fournie de 60 secondes.
• UNKNOWN : indépendance réelle des fournisseurs et capacité de remboursement.
• INSUFFICIENT EVIDENCE : mises à jour d’oracle ou audit garantissent la solvabilité.

• Utiliser le heartbeat comme règle d’acceptation du consommateur.
• Ignorer la paire ou les décimales.
• Supposer que l’audit couvre chaque dépendance.

Calculer âge du flux et réponse normalisée. Décider l’acceptation selon la règle fournie. Cartographier une panne de remboursement dans la route et nommer deux contrôles autres que la fraîcheur.

Fournissez les calculs ou annotations, le tableau affirmations/sources et les limites. Répartition suggérée : étude 12 minutes, exercice 8, correction et quiz 10 ; estimation à calibrer.

• Vérifier paire/réseau/unités.
• Calculer l’âge selon la règle du consommateur.
• Cartographier les dépendances amont partagées.
• Préserver les limites d’audit et d’oracle.

L’évaluation d’oracle combine identité, unités, fraîcheur et dépendances économiques. Mécanismes composables et audits restent des preuves limitées.

• Cartographier dépendances des oracles et de composabilité.
• Identifier limites des données périmées et des prix locaux.

P11-L08 après examen de la correction.

NONE dans le catalogue faisant autorité. Le jeu fictif ou paquet hors ligne fourni suffit ; aucune fonctionnalité payante ni capacité Production non vérifiée n’est nécessaire. Les métadonnées de laboratoire ou de certification désignent des associations en aval, pas des conditions d’accès ni des distinctions délivrées en direct.

• [ORACLE] Chainlink — Aperçu des flux de données — Agrégation, dépendances proxy et limites d’horodatage/écart/heartbeat. Vérifié le 2026-10-01; repère turn12view3.
• [V2] Livre blanc du cœur d’Uniswap v2 (mars 2020) — Rapport des réserves, produit constant et invariant avec frais sur l’entrée ; propre à la version, pas une observation d’un déploiement actif. Vérifié le 2026-10-01; repère turn14view0.