AI come "cattivo", l'assicurazione DeFi ha bisogno di un test di stress

Test di collisione per il tesoro DeFi: Firelight intende utilizzare l'AI per cercare il "prossimo incidente".

Autore: @jrdothoughts

Compilato da: AididiaoJP, Foresight News

Le zone cieche dell'assicurazione DeFi: non aver mai avuto un incidente non significa essere al sicuro

Iniziamo con una battuta di umorismo nero: "Il nostro nuovo aereo è assolutamente sicuro, non è mai caduto."

"Da quanto tempo vola?"

"... Circa due volte."

Sostituiamo l'aereo con un tesoro DeFi e la storia diventa familiare: sei mesi di prelievi senza problemi, nessun attacco, rendimenti piuttosto buoni. Questo è certamente una prova. Ma in questi sei mesi, ha mai affrontato congestione di rete, con i collaterali che si sono disancorati, i fornitori di liquidità (LP) che si sono affrettati a ritirarsi, o oracoli che non si sono aggiornati? Probabilmente no.

Una storia pulita può solo dimostrare cosa ha sopportato un sistema. L'assicurazione deve chiedere: cosa potrebbe affrontare in futuro?

Questa è l'opportunità che Firelight ha visto: determinare il prezzo in base ai modi in cui si formano le perdite, e non solo guardare se le perdite si sono già verificate. La storia serve a fissare un ancoraggio, la simulazione esplora scenari alternativi, l'AI cerca vulnerabilità e il capitale fornisce garanzie.

La storia è una foto, ma il sistema può cambiare

I dati storici sulle perdite sono una foto di una macchina che funziona in determinate condizioni. Quando la macchina cambia, la foto deve essere riesaminata.

Un tesoro ha aggiunto un nuovo tipo di collaterale, ha cambiato oracolo e ha aumentato la leva. Il nome non è cambiato, il logo non è cambiato, ma il rischio è già molto diverso. I mutuatari, i liquidatori e gli LP all'interno non sono solo numeri fermi in un foglio di calcolo. Reagiranno agli incentivi e, se qualcosa va storto, vorranno tutti uscire dalla stessa porta.

È come una mappa del traffico disegnata in base alla situazione abituale di un martedì. Di solito sembra piuttosto accurata, ma se il ponte principale è chiuso, non funziona più. La mappa non è sbagliata, è cambiata la situazione stradale.

Quindi, per Firelight, la vera domanda non è solo "questo protocollo è stato mai hackerato", ma: quali permessi esistono? Quali dipendenze sono veramente importanti? Quando tutti si affrettano a uscire, quali percorsi di liquidazione possono ancora essere percorsi? Il framework pubblico di Firelight ha già separato le vulnerabilità tecniche dalle fragilità economiche, piuttosto che mescolarle in un punteggio di sicurezza.

L'assicurazione si concentra sulla struttura attuale del sistema e sulle relazioni di dipendenza, non sul marchio che ha mantenuto fino ad oggi.

Le assicurazioni contro le catastrofi hanno già scritto la sceneggiatura

Le compagnie di assicurazione tradizionali non hanno abbandonato la modellazione dell'incertezza. Gli assicuratori contro le catastrofi hanno sempre fatto una cosa: simulare come si verificano le catastrofi, quali beni saranno esposti, quanto è fragile la struttura e quanto dovrà essere pagato alla fine del contratto. Gli uragani che hanno colpito in passato non rappresentano tutti gli uragani che potrebbero verificarsi in futuro.

Anche DeFi ha bisogno di un proprio modello di catastrofi. Solo che le catastrofi passano da uragani a guasti degli oracoli, gli oggetti colpiti passano da edifici a posizioni di prestito, le vulnerabilità passano dalla qualità della costruzione a buffer collaterali e progettazione della liquidazione, e infine si calcola il pagamento in base ai termini di copertura.

Il modello di catastrofi chiede: cosa succede quando un uragano colpisce una città? Il modello DeFi chiede: cosa succede quando un guasto si diffonde lungo la mappa delle dipendenze?

Firelight ha discusso pubblicamente di come scomporre i rischi, calibrare storicamente, utilizzare simulazioni Monte Carlo, modelli linguistici e apprendimento rinforzato, integrandoli in un laboratorio di test di collisione finanziaria. È importante notare che questa è una direzione proposta, non una dichiarazione che ogni parte sia già operativa.

C'è un'altra cosa da chiarire: Firelight definisce il proprio prodotto come una copertura basata su protocollo, piuttosto che un contratto di assicurazione tradizionale. L'analogia con l'assicurazione si riferisce alla disciplina di copertura, non alla qualificazione legale del prodotto.

Come costruire un laboratorio di test di collisione finanziaria

Il primo passo è fissare lo stato iniziale, assicurandosi che possa essere riprodotto. Versione del contratto, saldi, posizioni collaterali, impostazioni degli oracoli, regole di liquidazione e liquidità di mercato devono essere bloccati. Altrimenti, se i risultati di due simulazioni non corrispondono, potrebbe essere solo perché i punti di partenza sono diversi, e non si sta testando lo stesso sistema.

Il secondo passo è separare esecuzione e assunzioni. I fork della blockchain possono eseguire la logica dei contratti reali, ma non possono generare dal nulla la liquidità di domani, i prezzi off-chain e il comportamento umano. Questi devono essere modellati esplicitamente. Test basati su fork e agenti sono già stati precedentemente utilizzati nella ricerca DeFi.

Il terzo passo è assegnare vari partecipanti all'ambiente di simulazione. Mutuatari, liquidatori, depositanti e LP, ognuno con limitazioni di capitale e incentivi. Ma non si può dare a nessuno il ruolo principale: i liquidatori non possono fare transazioni in perdita solo per ottenere un finale soddisfacente. I ruoli non devono necessariamente utilizzare modelli linguistici complessi; regole semplici e trasparenti possono a volte essere migliori, più veloci e più facili da riprodurre. I fallimenti a livello tecnico devono comunque essere affrontati attraverso test di fuzzing, revisioni del codice e iniezioni di guasti; questi metodi e le simulazioni economiche devono procedere in parallelo, non sostituirsi a vicenda.

Il quarto passo è creare distruzione. Salti di prezzo, ritardi negli aggiornamenti degli oracoli, riduzione della liquidità e interruzioni nell'esecuzione devono essere testati. Non solo modificare l'ampiezza, ma anche l'ordine. Ritirare liquidità prima di uno shock di prezzo e ritirarla dopo può portare a risultati completamente diversi.

Alla fine della simulazione, non dovrebbe emergere un punteggio di sicurezza generico, ma una catena di perdite: quale posizione fallisce per prima, quanto viene recuperato e come si espande il gap. Solo con questa catena si possono determinare i limiti di copertura e i requisiti di capitale, o semplicemente dare una risposta di "non coperto".

Lasciare che l'AI sieda nel "posto del cattivo", ma non cambiare le leggi fisiche

L'uso più intuitivo dell'AI è leggere codice e documenti. I modelli linguistici possono analizzare le dipendenze, spiegare gli aggiornamenti e proporre scenari di fallimento. Ma una storia che suona credibile non significa aver trovato una vulnerabilità; ha comunque bisogno di prove.

Ciò che è più interessante è far sì che l'AI cerchi attivamente vari scenari possibili. Le simulazioni Monte Carlo campionano da distribuzioni preimpostate, il che è utile; ma le combinazioni veramente problematiche potrebbero essere troppo rare, e il campionamento casuale nella maggior parte dei casi ripete solo situazioni ordinarie.

I test di stress adattivi, al contrario: gli agenti nel simulatore scelgono fattori di disturbo, cercando attivamente percorsi di fallimento credibili. Questo approccio è già stato dimostrato da chi ha utilizzato l'apprendimento rinforzato nei test di guida autonoma. Gli agenti possono cambiare il tempo, ma non possono riscrivere le leggi fisiche.

Nell'impostazione proposta da Firelight, gli agenti possono regolare i ritardi degli oracoli, i ritiri di liquidità e il tasso di presenza dei liquidatori all'interno dei confini della realtà. Trovare percorsi distruttivi viene premiato, mentre le frodi vengono punite. Un cattivo con capitale illimitato e poteri divini non è un modello di copertura utile.

Poi si lascia che l'AI raggruppi le traiettorie di fallimento, selezionando il prossimo lotto di esperimenti che può ridurre al minimo l'incertezza. Centinaia di disastri apparentemente diversi potrebbero condividere lo stesso collo di bottiglia di liquidazione. Questo ha valore operativo.

La velocità è importante. Metodi di approssimazione a basso costo filtrano prima un gran numero di scenari, mentre test di esecuzione costosi vengono poi ripetuti in più ambienti di test indipendenti per riprodurre scenari importanti. Ma le scorciatoie devono essere verificate. Accelerare simulatori errati non farà altro che farli commettere errori con maggiore sicurezza.

L'AI svolge il ruolo di conducente nei test di resistenza, non di giudice della sicurezza. Essa indica cosa controllare, mentre il motore di esecuzione, gli esperti del settore e le prove decidono se questa scoperta regge.

Dalla traiettoria delle perdite ai termini di copertura

Immagina un tesoro di prestiti ipotetico: il prezzo dei collaterali scende, gli LP si ritirano, gli oracoli aggiornano in ritardo. I liquidatori, sebbene entrino in gioco, vengono divorati dallo slippage, e alla fine il debito del mutuatario supera il prezzo reale a cui il collaterale può essere venduto.

Facciamo alcune serie di confronti: lasciare solo scendere il prezzo; far scendere il prezzo mentre si ritira liquidità; far interagire più fattori insieme. Solo così si può capire se il vero punto debole è nel prezzo, nella profondità del mercato, o se deriva dall'interazione tra entrambi.

Supponiamo che un'operazione di esempio generi 2 milioni di dollari di perdite ammissibili, una franchigia di 500.000 dollari e un limite di copertura di 1 milione di dollari. La franchigia assorbe 500.000 dollari, si ipotizza che la copertura paghi 1 milione, e i restanti 500.000 cadono al di fuori del limite.

Questi sono termini di esempio fittizi, non un'offerta di Firelight e non risultati di simulazione reali. L'ammissibilità, il recupero, le esclusioni e le sovrapposizioni devono ancora essere chiariti.

La chiave è: avere perdite economiche non significa necessariamente ricevere un pagamento. La simulazione è utile solo se influisce sulla decisione di copertura—ad esempio, abbassando il limite di copertura, richiedendo controlli più rigorosi, mantenendo più capitale, o semplicemente rifiutando la copertura. Anche se l'animazione delle catastrofi è ben fatta, non è ancora una decisione finanziaria.

Trovare percorsi di fallimento non significa calcolare la probabilità

Supponiamo che un agente antagonista abbia compromesso il sistema nel 30% dei test. Questo significa che il sistema ha una probabilità di fallimento del 30%? Non necessariamente. Questo agente è stato progettato per trovare vulnerabilità.

Scoprire un fallimento risponde alla domanda "come potrebbe andare male, fino a che punto?" Stimare la probabilità risponde alla domanda "con quale frequenza queste condizioni si verificano durante il periodo di copertura?" Confondere i due è creare una falsa precisione.

Concettualmente, il pagamento atteso è l'importo del pagamento in ogni scenario, moltiplicato per la probabilità che quello scenario si verifichi, e poi sommato. Queste probabilità devono essere supportate da prove, e le assunzioni devono essere chiaramente scritte. Se non ci sono stime affidabili, si devono usare intervalli, limiti conservativi e vincoli di stress, piuttosto che inventare numeri precisi fino ai decimali.

Il pagamento atteso non è uguale a tutti i premi. Il capitale deve coprire anche i rischi tail, i costi operativi e l'incertezza, e i rischi tail sono spesso piuttosto brutti. A livello di portafoglio, le dipendenze condivise possono anche far scattare più contratti contemporaneamente.

Il framework di capitale pubblico di Firelight ha già considerato la concentrazione e il ritiro dei collaterali. La simulazione dovrebbe testare entrambe le estremità: una è l'aumento delle richieste di risarcimento, l'altra è il supporto degli asset che si deprezzano simultaneamente, o diventano più difficili da vendere. Se in caso di una grande catastrofe il capitale si riduce, il pool di copertura non può essere stimato solo sulla base delle perdite medie.

Chi testerà la "macchina per testare la pressione"?

I simulatori possono essere logicamente coerenti, ma le conclusioni possono essere completamente errate. Eseguire un milione di volte con impostazioni di liquidatori irrealistiche non è altro che ripetere lo stesso errore un milione di volte. Eseguire più volte può ridurre l'errore di campionamento, ma l'errore del modello stesso non diminuirà automaticamente.

Un laboratorio affidabile farà quattro cose: rivedere eventi noti, testare con dati fuori campione, confrontare modelli costruiti indipendentemente da diversi team e regolare le assunzioni sul comportamento dei partecipanti. Snapshot, semi casuali e registri di esecuzione devono essere archiviati, affinché le scoperte chiave possano essere replicate. E bisogna ripetere la domanda: ciò che l'AI ha trovato è una vulnerabilità del protocollo o un bug del simulatore?

Nessun test può dimostrare di aver trovato tutti i percorsi di catastrofe. Proprio perché ci sono dipendenze sconosciute e comportamenti mai visti, ci sarà bisogno di buffer di capitale, esclusioni e moderazione nella copertura.

I confini del contratto devono essere chiariti. Nuove prove possono influenzare la futura determinazione dei prezzi e la capacità, ma non dovrebbero trasformare la copertura esistente in un bersaglio mobile. Il framework pubblico di Firelight gestisce separatamente il monitoraggio continuo del rischio e le tariffe fisse durante il periodo di copertura. L'apprendimento continuo e il mantenimento degli impegni possono coesistere; ma modificare gli impegni dopo che il pericolo è emerso non è accettabile.

Conclusione: imparare prima che si verifichino le perdite

Il valore più grande è integrare la copertura nel processo di sviluppo. Quando il sistema subisce cambiamenti significativi, vengono attivati test corrispondenti; i risultati dei test influenzano le nuove decisioni di copertura; eventi reali aiutano a migliorare la prossima versione del modello. Più è ben fatto il lavoro ingegneristico, più si rifletterà infine sui prezzi e sulla disponibilità della copertura.

Le storie di risarcimento storiche sono un recupero post-evento. Le simulazioni permettono a Firelight di chiarire in anticipo: come potrebbe guastarsi questo sistema.

L'AI è responsabile dell'espansione dell'ambito di ricerca, le prove vincolano le sue conclusioni e il capitale è responsabile dell'adempimento degli impegni. L'obiettivo non è prevedere ogni catastrofe, ma dopo aver compreso cosa potrebbe affrontare, investire capitale per sostenere quelle perdite che devono essere affrontate.