Vai al contenuto
Financial Context Wiki

Prezzi di oracolo obsoleti

Il prezzo di un oracolo è obsoleto per un consumatore quando l'ora di aggiornamento documentata è più vecchia dell'età massima ammessa per l'azione; una gestione sicura richiede anche validità del feed, controlli del sequencer, fallback e ripristino controllato.

Aggiornato

Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.

Risposta diretta

Il valore di un oracolo è obsoleto per una specifica azione del consumatore quando age = consumerClock - sourceTimestamp supera il maxAge configurato per quell’azione. Un prezzo invariato può essere ancora recente e un valore pubblicato da poco può essere economicamente errato. Il consumatore deve anzitutto rifiutare timestamp mancanti o futuri e risposte non valide, quindi applicare una politica di accettazione specifica per feed, asset, blockchain, orari di mercato e azione.

Heartbeat e soglie di deviazione sono trigger di pubblicazione, non garanzie di aggiornamento né accordi sul livello di servizio. Un report può subire ritardi dopo il trigger, mentre il mercato può muoversi meno della soglia quando un’azione richiede un’età massima inferiore. Gli oracoli pull aggiungono un altro confine: il chiamante potrebbe dover inviare un aggiornamento autenticato prima della lettura e il contratto deve rifiutare aggiornamenti più vecchi del limite dichiarato.

Su una L2, lo stato del sequencer e il periodo di grazia dopo il ripristino costituiscono una barriera separata. Superarla non dimostra che il prezzo dell’asset sia recente, che la L2 sia finalizzata o che tutti gli utenti abbiano avuto pari accesso. Le fonti fallback e gli ultimi prezzi validi sono modalità controllate di degrado, non la verità; ogni fonte e percorso di ripristino richiede unità, timestamp, indipendenza, permessi, azioni consentite e regole di riconciliazione.

Come funziona

  1. Fissare blockchain, blocco e orologio, contratto consumatore e azione, proxy e aggregatore del feed, coppia e decimali, versione dell’interfaccia, configurazione fallback e stato degli upgrade.
  2. Leggere la risposta esatta attraverso l’interfaccia distribuita e gestire revert o assenza di dati. Validare risposta, stato o confidenza ove applicabile, sourceTimestamp != 0 e sourceTimestamp <= consumerClock prima di sottrarre.
  3. Registrare heartbeat, deviazione, orari di mercato e configurazione di pubblicazione, quindi impostare un maxAge indipendente per ogni azione. Definire esplicitamente il confine, per esempio accettare age <= maxAge e rifiutare age > maxAge.
  4. Nelle distribuzioni L2 supportate, validare inizializzazione e stato del feed del sequencer, calcolare dal campo documentato il tempo dal ripristino e applicare il periodo di grazia configurato prima di verificare separatamente l’aggiornamento del prezzo.
  5. Tracciare ogni componente necessario di prezzi composti, rapporti e fallback. Normalizzare direzione e unità e limitare l’aggiornamento effettivo in base alla dipendenza necessaria più vecchia, non al timestamp più recente.
  6. Definire stati normale, degradato e in pausa per ogni azione. Nuovi prestiti, coniazione o leva possono fallire in modalità chiusa mentre rimborso o aggiunta di garanzia restano disponibili; testare prezzi obsoleti, fallback e ripristinati rispetto a esposizione, liquidità e capacità dei keeper.
  7. Monitorare cambi di fonte e proxy, latenza, tassi di rifiuto, stato del sequencer, divergenza tra fonti e orari; provare indisponibilità, guasto del fallback, salto al ripristino, liquidazioni concentrate, MEV, contabilizzazione dei crediti inesigibili e ritorno alla modalità normale.

Nelle interfacce di tipo Chainlink, latestRoundData() può esporre identificativo del round, risposta con segno, ora di inizio, ora di aggiornamento e un campo round legacy. L’API corrente documenta answeredInRound come deprecato, quindi una disuguaglianza storica non deve essere presentata come regola corrente universale: occorre verificare proxy, aggregatore e implementazione esatti. Un timestamp indica quando è stato aggiornato lo stato documentato del feed, non che il valore sia eseguibile per qualunque quantità. In Solidity, block.timestamp è il timestamp del blocco corrente entro i vincoli del consenso, non un oracolo esterno dell’ora civile.

Esempi svolti

  • Confine dell’età massima. Siano consumerClock = 1,800,000,000 e sourceTimestamp = 1,799,999,100, quindi age = 900 seconds = 15 minutes. Una politica maxAge = 600 seconds rifiuta il valore per 300 seconds; una politica maxAge = 1,200 seconds lo accetta con 300 seconds di margine. Lo stesso valore può essere accettabile per un’azione e obsoleto per un’altra.
  • Il trigger non è aggiornamento. L’ultimo prezzo pubblicato è 100.00, la soglia di deviazione è 1% e l’heartbeat è 3,600 seconds. Dopo 2,700 seconds, un prezzo di mercato osservato pari a 100.80 dista solo 0.8%, quindi nessuno dei trigger didattici è scattato. A 101.20, la deviazione è 1.2% e può avviare la pubblicazione, ma il consumatore continua a leggere 100.00 finché non viene incluso un nuovo report valido.
  • Doppia barriera L2. Un feed del sequencer comunica lo stato operativo con startedAt = 1,799,996,400, consumerClock = 1,800,000,000 e grace = 3,600 seconds; sono trascorsi esattamente 3,600 seconds. Con una politica che blocca finché elapsed <= grace, l’azione resta bloccata e diventa ammissibile a 3,601 seconds. L’ammissibilità dipende ancora dal timestamp del prezzo, dalla risposta e da ogni altro controllo del consumatore.
  • Salto di ripristino. Con 10 ETH di garanzia, 12,000 USD di debito e soglia di liquidazione del 75%, un valore obsoleto di 2,000 USD/ETH produce healthFactor = 10 * 2,000 * 0.75 / 12,000 = 1.25. Un valore ripristinato di 1,400 USD/ETH produce 0.875. Con questi dati didattici il conto diventa liquidabile, ma l’esecuzione dipende ancora da regole, liquidità, keeper, gas, ordinamento e disponibilità della blockchain.

Rischi

  • Blockchain, feed, proxy, aggregatore, coppia di asset o versione dell’interfaccia errati.
  • Il consumatore legge una risposta senza timestamp o stato documentato.
  • Timestamp zero o futuro e sottrazione con underflow non vengono rifiutati.
  • L’età massima è troppo ampia per asset, azione, orari o volatilità.
  • L’età massima è troppo restrittiva e causa denial of service o impedisce la riduzione del rischio.
  • L’heartbeat è trattato come scadenza garantita o accordo sul livello di servizio.
  • Deriva o basis sotto soglia si accumulano senza attivare il trigger di deviazione.
  • Un report attivato è ritardato da fonte, firmatari, rete, gas, relay o blockchain.
  • Un controllo del round deprecato o specifico dell’implementazione viene applicato universalmente.
  • Cambi di feed, proxy, aggregatore, heartbeat, deviazione o interfaccia passano inosservati.
  • Si ignora la semantica di mercato chiuso, festività, pausa o dati riportati.
  • Un prezzo composto o rapporto sembra recente mentre un componente richiesto è obsoleto.
  • Lo stato del sequencer L2 è ignorato, non inizializzato, ritardato o letto sulla rete errata.
  • Il periodo di grazia manca, è configurato male o presenta un errore al confine.
  • Il controllo sul sequencer passa mentre il prezzo resta obsoleto o non disponibile.
  • Tempo L1, tempo del blocco L2, osservazione, pubblicazione e ora civile vengono confusi.
  • Un aggiornamento pull manca, è troppo vecchio, selettivo, malformato o privo di fondi.
  • Un fallback o ultimo valore valido è obsoleto, correlato, scalato diversamente o circolare.
  • Fail-open consente azioni insicure, mentre fail-closed indiscriminato blocca rimborso, aggiunta di garanzia o ripristino ordinato.
  • Salto di ripristino, liquidazioni concentrate, MEV, scarsa liquidità, corsa alla pausa o riconciliazione dei crediti inesigibili causano perdite secondarie.

Idee errate comuni

  • «L’heartbeat garantisce un aggiornamento recente a ogni intervallo». È una configurazione di trigger; guasti alla fonte o alla blockchain possono comunque ritardare la pubblicazione.
  • «Un timestamp recente prova un prezzo corretto ed eseguibile». Prova solo l’ora documentata; qualità, unità, confidenza, profondità e logica del consumatore restano separate.
  • «Un’unica età massima vale per ogni feed e azione». Asset, orari, blockchain e azioni di prestito, liquidazione, negoziazione e regolamento hanno esigenze diverse.
  • «Sequencer operativo significa poter riprendere tutto subito». Periodo di grazia e aggiornamento del prezzo sono barriere indipendenti e possono aggiungersi altre politiche.
  • «Fallback o revert di ogni funzione è sempre la scelta più sicura». Un fallback debole valuta male il rischio; un blocco indiscriminato può impedire rimborso o miglioramento della garanzia.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...