Guadagni:
- Capacità di comprendere gli elementi costitutivi della DeFi come AMM, pool di liquidità, oracle e prestito flash e di utilizzare l'intelligenza artificiale nella spiegazione dei meccanismi e nella stesura degli scenari
- Essere in grado di distinguere che la maggior parte dei rischi DeFi sono vulnerabilità della logica economica/aziendale, non bug del codice, e che l’intelligenza artificiale è debole nella vulnerabilità economica originaria
- Riuscire a capire che la sicurezza economica si prova con la simulazione, non con il pensiero, e che la dipendenza dagli oracoli è il punto più fragile.
La DeFi (finanza decentralizzata) è il dominio di maggior valore e più attaccato di Web3. Scambi, protocolli di prestito, pool di liquidità: tutto funziona come un codice e muove milioni di dollari in un ambiente ostile. In questa unità utilizzeremo l'intelligenza artificiale come assistente per l'analisi del protocollo; Impareremo a comprendere la liquidità, i prezzi, il MEV e gli attacchi economici e dove l’intelligenza artificiale è utile e inadeguata in quest’area contestuale.
Gli elementi costitutivi di base della DeFi
- AMM (Automated Market Maker): un meccanismo di scambio che fissa i prezzi tramite una formula (ad esempio x·y=k) anziché abbinare acquirenti e venditori.
- Pool di liquidità: un fondo comune in cui gli utenti depositano token e hanno luogo gli scambi.
- Protocollo di prestito: prestito contro garanzia; La liquidazione avviene quando il valore della garanzia diminuisce.
- Oracle: la fonte di dati che porta il prezzo del mondo esterno al protocollo: la dipendenza più critica e fragile della DeFi.
- Prestito flash: prestito preso senza garanzie in un'unica operazione e restituito nella stessa operazione; Ha sia usi legittimi che uno strumento di attacco.
MEV e attacchi economici
Il MEV (Maximal Extractable Value – il valore estratto dall’autorità per ordinare/aggiungere/rimuovere transazioni) è una classe di rischio specifica della DeFi. Le transazioni in sospeso appaiono nel pool pubblico (mempool); Questa visibilità apre la porta ai seguenti attacchi:
- Front-running: vedere una transazione redditizia e inserirvi davanti la propria transazione.
- Attacco sandwich: effettuare transazioni prima e dopo l'acquisto della vittima e trarre profitto dalla differenza di prezzo.
- Manipolazione Oracle: ingannare il protocollo modificando istantaneamente il prezzo di un pool, solitamente con un prestito lampo.
Questi attacchi non nascono dal "bug" del codice, ma dalla sfruttabilità del disegno economico. È qui che l’intelligenza artificiale ha maggiori difficoltà: l’intelligenza artificiale che è brava a scansionare il codice tecnico spesso non riesce a rilevare una vulnerabilità economica specifica del protocollo.
Attenzione: la maggior parte delle vulnerabilità DeFi non sono "bug di codice" ma vulnerabilità di logica economica/aziendale. La scansione del codice standard dell'IA non li rileva; Questo è il campo che richiede la maggior parte delle competenze umane, della simulazione e della modellazione.
Il ruolo dell’intelligenza artificiale nell’analisi DeFi
1. Descrizione del meccanismo. L’intelligenza artificiale è potente nello spiegare in un linguaggio semplice come funziona un protocollo complesso (ad esempio un AMM basato su curve). Ciò fornisce un rapido accesso all'analisi.
2. Generazione di uno scenario/controipotesi. "Con quale movimento dei prezzi questo protocollo sul debito entrerà in crisi di liquidazione?" L'intelligenza artificiale produce bozze di scenari con domande come; questi sono testati mediante simulazione.
3. Ricordare modelli di attacco noti. L’intelligenza artificiale evoca gli schemi degli attacchi DeFi passati (manipolazione degli oracoli, rientro, spirale di liquidazione) come una lista di controllo.
4. Bozza del piano di simulazione. L’intelligenza artificiale può elaborare un piano per quali scenari testare; ma la simulazione stessa viene eseguita con lo strumento (Foundry, Tenderly).
Prompt debole / Prompt forte
Suggerimento debole:
Questo protocollo DeFi è sicuro?
Suggerimento potente:
Il tuo ruolo: analista del protocollo DeFi. Esaminare il meccanismo del protocollo di seguito. Consideriamo uno per uno i seguenti vettori di attacco economico: manipolazione dell’oracolo (con prestito flash), sandwich/front-running, spirale di liquidazione, effetto di ritiro della liquidità. Per ciascun vettore: come innescare, quale condizione è richiesta, possibile impatto. Queste sono le ipotesi da verificare MEDIANTE SIMULAZIONE; Non dire sicuramente "sicuro/non sicuro". GENERARE il codice di attacco effettivo; Descrivere il rischio solo a scopo difensivo.
Quattro modelli copiabili
1) Descrizione del meccanismo:
Spiegare in un linguaggio semplice, passo dopo passo, il meccanismo di prezzo/liquidità di questo protocollo: cosa succede quando un utente effettua una transazione, come viene determinato il prezzo, quali dipendenze esterne ci sono? Segna la parte che non capisci o che lasci poco chiara.
2) Superficie di attacco economico:
Mappare la superficie di attacco economico di questo protocollo: quali presupposti possono essere sfruttati in oracle, liquidità, garanzie, liquidazione, governance? Scrivi ogni rischio con una condizione ("e se"). Presentatela come ipotesi da confermare tramite simulazione.
3) Scenario di stress:
Considera i seguenti scenari: se il token collaterale scende del 50%, se il prezzo dell'oracolo devia momentaneamente del 30%, se l'80% della liquidità viene ritirato, quale sarà il protocollo? Annota l'effetto a catena di ogni scenario. Non pretendere la precisione numerica; Specificare che la simulazione è obbligatoria.
4) Corrispondenza dei modelli di attacco storici:
La progettazione di questo protocollo presenta condizioni simili a quali dei modelli di attacco DeFi noti (ad esempio oracolo a fonte singola, prezzo di apertura del prestito flash)? Sottolineare le somiglianze a fini difensivi; Non compiere il passo dell'exploit, produrrà solo un punto di attenzione.
Tre mini custodie (in numeri)
Caso 1: rischio Oracle individuato tempestivamente. Un team stava progettando un nuovo protocollo sul debito. Durante la spiegazione del meccanismo, YZ ha sottolineato l'ipotesi che "il prezzo viene prelevato da un unico pool e può essere manipolato con prestiti flash". Il team lo ha confermato nella simulazione e è passato a TWAP + multi-sourcing. Perdita stimata evitata: l'intero valore bloccato del protocollo. Lezione: l’intelligenza artificiale è preziosa nell’evocare modelli conosciuti.
Caso 2: l'IA non ha colto la vulnerabilità originale. In un altro protocollo la vulnerabilità era un errore economico unico risultante dall’interazione di due meccanismi (premio + liquidazione). L'IA ha trovato ogni meccanismo "impeccabile" uno per uno; Impossibile vedere l'interazione. Modellatore umano e simulazione catturati. Lezione: mentre i componenti sono giusti, l’economia complessiva è il punto cieco dell’intelligenza artificiale.
Caso 3 — Il piano di simulazione ha consentito di risparmiare tempo. Un analista ha elaborato 15 diversi scenari di stress nell’intelligenza artificiale invece di pianificarli manualmente; poi l'ho eseguito alla Foundry. La pianificazione è scesa da 1 giorno a 2 ore; ma l'interpretazione dei risultati e la decisione spettavano all'uomo. Lezione: piani AI, misure dei veicoli, decisioni umane.
L'indispensabilità della simulazione
Nella DeFi, la sicurezza non si dimostra “pensando”; È testato mediante simulazione. La robustezza economica di un protocollo può essere compresa analizzando numericamente diversi scenari di prezzo, liquidità e attacco. L’intelligenza artificiale può pianificare e redigere il codice di queste simulazioni; ma sono gli strumenti e le persone che producono e interpretano i risultati. L'affermazione "probabilmente durevole" prodotta dall'IA non è un risultato di simulazione e non può essere presentata come tale.
Suggerimento: quando ricevi una valutazione del rischio DeFi dall’intelligenza artificiale, dovresti chiedere a ciascuna ipotesi “con quale simulazione lo testerò?” Trasformalo in una domanda. Una richiesta di sicurezza che non può essere testata non è una garanzia nella DeFi.
Errori comuni
- Scansionare il deficit economico come un bug di codice. I rischi della DeFi riguardano principalmente la logica aziendale.
- Confidare che l'IA dica "sicuro" e saltare la simulazione. È necessario effettuare dei test.
- Convalidare i componenti uno per uno e saltare l'interazione. L’economia nel suo complesso è critica.
- Affidarsi a Oracle da un'unica fonte. Il disastro DeFi più comune.
- Ignorando MEV/front-running. Dimenticando il fatto del mempool pubblico.
- Generazione del codice di exploit. Solo l’analisi difensiva è legittima.
In sintesi
- La DeFi è uno spazio di alto valore e ostile; I rischi sono per lo più di logica economico/aziendale.
- MEV, front-running, sandwich e manipolazione degli oracoli sono classi di attacchi specifici della DeFi.
- L’intelligenza artificiale è forte nella spiegazione dei meccanismi e nella stesura degli scenari; Il deficit economico originario è debole.
- La sicurezza economica si dimostra con la simulazione, non con il pensiero; Piani AI, misure sui veicoli.
- La dipendenza da Oracle è il punto più vulnerabile della DeFi; sono necessarie più risorse e TWAP.
Compito dell'applicazione
Scegli un AMM o un protocollo di prestito (con documentazione chiara). Applicare all'IA le istruzioni "descrizione del meccanismo" e "superficie di attacco economico". Per ogni ipotesi di rischio prodotta dall’intelligenza artificiale, “con quale simulazione la testerei?” Rispondi alla domanda. Quindi trova il rapporto di audit effettivo di quel protocollo e confronta i risultati effettivi con i rischi segnalati dall’IA: cosa ha catturato l’IA, cosa ha mancato?
lista di controllo
- [ ] Ho discusso i rischi in due dimensioni: codice + economia.
- [ ] Ho valutato MEV/front-running.
- [ ] Ho anche esaminato la dipendenza da Oracle.
- [ ] Ho messo in discussione l'interazione delle componenti (l'intera economia).
- [ ] Ho collegato ciascuna ipotesi ad un piano di simulazione.
- [] Ho sostituito la "sicurezza" dell'IA con la simulazione.
- [ ] Ho analizzato solo a scopo difensivo.