Bridge, oracoli e punti di rottura della DeFi

I sistemi connessi creano nuove dipendenze

Una blockchain può registrare i risultati delle transazioni all'interno del proprio ambiente, ma spesso le applicazioni hanno bisogno di informazioni o asset provenienti da altrove. Un oracolo fornisce a un contratto informazioni che hanno origine al di fuori del suo contesto di esecuzione. Un bridge cross-chain è un meccanismo che trasferisce informazioni o crea una rappresentazione del valore tra diverse reti blockchain. Entrambi ampliano le funzionalità, ma collegano sistemi che possono avere regole, ipotesi di sicurezza, amministratori e modalità di guasto differenti.

Definire decentralizzato un sistema non fa scomparire queste dipendenze esterne. In pratica, la sicurezza di una transazione può dipendere dal componente rilevante più debole, che potrebbe essere una fonte di dati sui prezzi, un account amministratore, un quorum di firmatari, un'interfaccia o un pool di liquidità. Questa lezione illustra la catena delle dipendenze e spiega come i professionisti possano individuare i punti in cui si verificano i guasti. Non ripete i contenuti dettagliati sulla sicurezza dei wallet e sulla gestione delle chiavi trattati nel Modulo 4.

Oracoli: introdurre fatti esterni nell'esecuzione

La pipeline dei dati

Uno smart contract può leggere direttamente i dati memorizzati sulla propria rete, ma non può determinare autonomamente il prezzo di un'azione, un'osservazione meteorologica o l'esito di un evento esterno a quella rete. Un sistema di oracoli in genere raccoglie informazioni da una o più fonti esterne, le elabora o le aggrega e rende un valore disponibile on-chain. Alcuni sistemi inviano aggiornamenti, altri rispondono a richieste. Un timestamp, una regola di aggiornamento e un'indicazione del livello di affidabilità possono essere importanti quanto il valore stesso.

Un oracolo non è necessariamente una singola persona o una singola azienda. Può coinvolgere diversi fornitori di dati, nodi, algoritmi di aggregazione o meccanismi di governance. La presenza di più fonti non implica necessariamente che siano indipendenti: diversi fornitori potrebbero basarsi, in ultima analisi, sullo stesso mercato o fornitore di dati. Se quell'input comune viene meno, la ridondanza apparente può trarre in inganno. L'espressione oracolo decentralizzato dovrebbe quindi indurre a chiedersi quanto siano effettivamente diversificati i dati e gli operatori.

Accuratezza, tempestività e incentivi

Tre domande aiutano a valutare un oracolo: le informazioni sono accurate per lo scopo previsto? Sono abbastanza aggiornate per l'azione da intraprendere? Gli attori possono trarre vantaggio dalla manipolazione della fonte o del processo di aggiornamento? Le risposte sono diverse. Un prezzo corretto comunicato con dieci minuti di ritardo può essere inutilizzabile in un sistema di garanzie soggetto a rapide variazioni. Un prezzo tempestivo proveniente da un mercato illiquido può essere facile da distorcere. Anche una mediana imparziale può essere errata se gli input sottostanti sono correlati.

Le applicazioni possono limitare l'età massima di un'osservazione, confrontarla con fonti secondarie o sospendere le operazioni sensibili quando gli input sembrano sospetti. Ogni soluzione comporta compromessi: rifiutare valori obsoleti può impedire esecuzioni errate, ma anche bloccare operazioni legittime. Un esaminatore legale o operativo dovrebbe individuare chi seleziona la fonte, chi modifica le soglie, cosa accade durante un'interruzione del servizio e se un accordo sull'utilizzo dei dati impone obblighi legalmente vincolanti.

Bridge: trasferire pretese tra blockchain

Lock-and-mint e altri design

Un design di bridge blocca un asset sulla Rete A ed emette una rappresentazione corrispondente sulla Rete B. Questa rappresentazione è spesso chiamata asset wrapped. Il suo valore dipende dalla capacità del meccanismo di verificare il blocco originale, impedire la creazione non autorizzata e rispettare il processo di riscatto. L'asset wrapped non è letteralmente lo stesso oggetto on-chain dell'asset bloccato. Può aggiungere una pretesa nei confronti del meccanismo del bridge o un meccanismo con ulteriori condizioni.

Altri design possono bruciare un asset su una rete e crearne uno corrispondente su un'altra nell'ambito di un sistema di emissione comune, oppure predisporre uno swap utilizzando la liquidità disponibile su entrambe le reti. Alcuni trasmettono messaggi cross-chain invece di rappresentare asset. Questi approcci comportano diverse ipotesi di fiducia. Un bridge di messaggi non implica necessariamente che gli asset siano detenuti in una riserva. Prima di definire un trasferimento come riscatto, scambio o spostamento della stessa unità, un professionista dovrebbe individuare il meccanismo esatto.

Verifica e ipotesi di fiducia

Un bridge deve determinare se un evento su un'altra blockchain si sia effettivamente verificato secondo le regole di quella blockchain. Alcuni sistemi utilizzano validatori o firmatari indipendenti per attestarlo. Altri si basano su prove verificabili secondo le regole della blockchain di destinazione, talvolta con ipotesi aggiuntive sulla disponibilità dei dati o sulla finalità. Nessuna delle due categorie è automaticamente sicura: contano l'implementazione del contratto, la finalità del consenso, la governance delle chiavi e la logica di aggiornamento.

Se il bridge accetta un messaggio falso, rilascia un asset bloccato senza autorizzazione o emette più rappresentazioni di quante ne consenta la copertura, le sue promesse possono venire meno. Anche le interruzioni operative su una delle due reti possono interrompere i trasferimenti. Un utente potrebbe vedere un asset addebitato su un lato ma non ancora accreditato sull'altro. Ciò non significa sempre che l'asset sia perso in modo permanente: la spiegazione corretta dipende dallo stato del messaggio, dalle regole di regolamento e dalla risposta all'incidente. Viceversa, una transazione contrassegnata come riuscita su una rete non dimostra in modo conclusivo che il processo cross-chain sia stato completato.

Componibilità e guasti a cascata

La componibilità consente alle applicazioni di collegarsi e riutilizzare le funzioni di altre applicazioni. Permette di offrire servizi utili, ma può anche propagare i guasti. Immaginiamo un contratto di prestito che accetta un asset wrapped come garanzia, ne determina il prezzo tramite un oracolo e si affida a un pool di trading esterno per la liquidazione. Un'unica interruzione nella copertura del bridge, nel feed dei prezzi o nella profondità del pool può influire sul protocollo di prestito anche quando il codice del protocollo funziona esattamente come programmato. Un sistema può essere corretto a livello locale e produrre comunque un risultato economicamente dannoso perché una dipendenza era errata.

Questo è un aspetto distintivo del rischio della DeFi moderna: i contratti possono interconnettersi più rapidamente di quanto le organizzazioni riescano a mappare le proprie esposizioni. Un diagramma delle dipendenze può rivelare che diversi servizi apparentemente indipendenti si basano sullo stesso amministratore, sulla stessa fonte di dati o sullo stesso bridge. L'analisi degli scenari di stress considera cosa succede se una dipendenza si interrompe, comunica informazioni errate o non riesce a completare il regolamento. Prende in considerazione le misure di ripristino, oltre all'errore iniziale.

Come si indagano i guasti

Diversi tipi di evidenze

Un esame tecnico di un incidente di solito inizia con una cronologia, la rete e i contratti interessati, le transazioni pertinenti, le versioni dei contratti, le modifiche alla governance e i log disponibili. Gli investigatori distinguono l'osservazione dall'interpretazione. Un trasferimento di token è un'osservazione; affermare che si è trattato di un prelievo autorizzato da un cliente è una conclusione che richiede ulteriori riscontri. Un bridge sospeso può non mostrare alcun trasferimento di asset e, al tempo stesso, costituire un incidente operativo significativo.

Le evidenze utili possono includere hash delle transazioni, registri di monitoraggio interni, avvisi di sicurezza pubblicati, modifiche al codice, definizioni degli eventi dei contratti e attestazioni dei fornitori di dati. Alcuni elementi sono pubblici; altri richiedono un accesso legittimo ai registri aziendali off-chain. L'attribuzione di un indirizzo sconosciuto a una persona o a un'organizzazione non dovrebbe basarsi su un'unica transazione o su un'etichetta non corroborata. La tracciabilità tecnica e la questione giuridica della responsabilità sono indagini distinte.

Quattro domande per un responsabile o un organo di vigilanza

Primo: cosa ci si aspettava che accadesse e quale contratto o servizio era responsabile di ciascuna fase? Secondo: cosa è effettivamente accaduto, secondo una sequenza di eventi verificabili in modo indipendente? Terzo: quali dipendenze o privilegi hanno reso possibile il risultato dannoso? Quarto: quali controlli o percorsi di escalation erano disponibili prima e dopo l'incidente? Questo quadro aiuta a distinguere le cause profonde dai sintomi secondari e sostiene raccomandazioni basate su evidenze, senza esprimere un giudizio d'investimento.

Contesto normativo e di governance

NIST IR 8202, Blockchain Technology Overview (2018), spiega gli smart contract e il ruolo degli oracoli dei dati nei meccanismi blockchain. Le Policy Recommendations for Decentralized Finance (DeFi) (dicembre 2023) di IOSCO affrontano le dipendenze da terze parti, compresi oracoli e bridge, e richiamano l'attenzione sull'identificazione e sulla gestione dei rischi sostanziali. Il Global Regulatory Framework for Crypto-Asset Activities (2023) del Financial Stability Board e i relativi lavori internazionali sottolineano la necessità di considerare l'interconnessione e i rischi transfrontalieri. Questi sono riferimenti di policy, non una prova automatica che un progetto specifico sia conforme alla normativa nazionale applicabile.

Ai fini AML/CFT, la Raccomandazione 15 del FATF e l'Updated Guidance on Virtual Assets and VASPs del FATF del 2021 inquadrano l'analisi di chi fornisce o facilita effettivamente i servizi disciplinati. Il semplice fatto di trasferire dati tra blockchain non esclude automaticamente un bridge da ogni normativa; allo stesso modo, la sola esistenza di codice open source non dimostra che ogni contributore sia un fornitore regolamentato. In base ai requisiti attuati a livello locale, possono sorgere questioni distinte ai sensi della Raccomandazione 16 del FATF quando un fornitore soggetto alle norme effettua un trasferimento di virtual asset che rientra nel perimetro previsto.

Un esame di un bridge dovrebbe chiedersi se un asset venga rappresentato o effettivamente trasferito, chi possa autorizzare i messaggi, chi detenga le riserve, se presenti, quale blockchain fornisca la finalità e cosa accada durante un'interruzione del servizio. Un esame di un oracolo dovrebbe chiedersi come vengono reperiti, aggregati e aggiornati i dati e come possono essere contestati. Quando non è possibile stabilire né l'una né l'altra cosa, la conclusione professionale appropriata è l'incertezza, non una fiducia desunta da una descrizione di marketing.

Sintesi: tracciare l'intero servizio, non l'etichetta

Consideriamo un servizio di prestito sintetico che utilizza un asset bridged. Un giorno, il bridge sospende i nuovi riscatti mentre l'oracolo continua a riportare un prezzo di riferimento esterno. Il protocollo di prestito potrebbe continuare a mostrare i valori delle garanzie, anche se liquidarle o riscattarle è diventato difficile. Un osservatore che controlla solo il saldo del contratto potrebbe sottovalutare il rischio. Un'analisi più completa esamina la copertura, la determinazione dei prezzi, la liquidità di esecuzione, lo stato della governance e il funzionamento del percorso dei messaggi del bridge.

La lezione più ampia è che la DeFi è una rete di dipendenze tecniche e organizzative. Una valutazione efficace non richiede di presumere che la tecnologia sia intrinsecamente inaffidabile o intrinsecamente sicura. Richiede di individuare gli effettivi punti di fiducia, distinguere gli eventi pubblici dalle dichiarazioni off-chain e spiegare i limiti in modo chiaro.

Focus d'esame: Definire un oracolo e un bridge cross-chain; distinguere a livello concettuale gli schemi lock-and-mint, burn-and-mint e basati sulla liquidità; individuare i rischi legati alle dipendenze e alla verifica dei messaggi; e valutare le evidenze prima di concludere perché si è verificato un incidente cross-chain o DeFi.