Il 4 maggio 2026 un utente su X ha convinto l’agente AI Grok, integrato con il bot di trading Bankr, a trasferire circa 3 miliardi di token DRB, tra i 130.000 e i 175.000 euro al cambio dell’epoca, fuori da un wallet che l’agente controllava. Il trucco non aveva nulla di sofisticato dal punto di vista crittografico: un NFT \u00abBankr Club Membership\u00bb inviato in regalo ha sbloccato permessi \u00abExecutive\u00bb nel wallet dell’agente, bypassando i normali limiti di trasferimento, e un messaggio in codice Morse pubblicato come risposta su X ha convinto il modello a tradurlo ed eseguirlo come un’istruzione legittima, cio\u00e8 inviare fondi a un indirizzo scelto dall’attaccante. Nessun bug nello smart contract, nessuna chiave privata rubata: solo un modello linguistico che ha eseguito un calcolo, quello che l’attaccante gli ha chiesto di fare, senza che nessuno potesse verificare in anticipo se il risultato fosse legittimo.<\/p>
L’episodio, catalogato nel database ufficiale degli incidenti AI dell’OCSE<\/a>, riassume bene il problema che il verifiable compute prova a risolvere. Man mano che agenti AI autonomi firmano transazioni, oracoli alimentano protocolli DeFi con dati elaborati da modelli di machine learning e i mercati predittivi si affidano a un’AI per interpretare un evento del mondo reale, la domanda cambia: non pi\u00f9 \u00abquesto sistema \u00e8 decentralizzato?\u00bb, ma \u00abposso verificare che questo calcolo sia stato eseguito correttamente, senza dover rifare il lavoro io stesso?\u00bb. Sono due domande diverse, e la crypto degli ultimi due anni ha iniziato a trattarle come tali, con un intero filone di progetti, da EigenCloud a Boundless, da Succinct a Phala Network, nato apposta per rispondere alla seconda.<\/p> Il termine verifiable compute indica un calcolo che produce, insieme al risultato, una prova a basso costo che quel risultato \u00e8 stato ottenuto correttamente, cosicch\u00e9 chi la riceve non debba ripetere l’intero calcolo per fidarsi. Il costo di verifica deve restare molto pi\u00f9 basso del costo di esecuzione originale: altrimenti tanto varrebbe rieseguire tutto da capo, vanificando lo scopo stesso della prova.<\/p> Vitalik Buterin ha inquadrato il tema in un saggio del gennaio 2024<\/a> che resta ancora oggi il riferimento concettuale del settore, proponendo una tassonomia in quattro categorie per le applicazioni che combinano crypto e AI e osservando che il nodo cruciale, in ognuna di esse, \u00e8 sempre lo stesso: come si fa a sapere che un output prodotto da un modello, spesso opaco e costoso da rieseguire, riflette davvero l’esecuzione onesta di quel modello, e non un dato inventato, un modello sostituito con uno pi\u00f9 economico o un input manipolato.<\/p> \u00c8 importante distinguere il verifiable compute dal semplice calcolo decentralizzato. Reti come Akash Network o Bittensor permettono di affittare potenza di calcolo, GPU comprese, da un mercato distribuito di provider invece che da AWS o Google Cloud: questo abbassa i costi e riduce la dipendenza da un singolo fornitore, ma non prova che il provider abbia eseguito il lavoro richiesto in modo onesto. Il verifiable compute affronta un problema diverso e pi\u00f9 stretto: non \u00abdove gira il calcolo\u00bb, ma \u00abcome faccio a fidarmi del risultato\u00bb. Torneremo su questa distinzione pi\u00f9 avanti, perch\u00e9 \u00e8 anche il modo pi\u00f9 semplice per capire cosa il settore intende davvero quando parla di AI \u00abverificabile\u00bb.<\/p> Il caso Grok\/Bankr non \u00e8 isolato. Nello stesso periodo, diversi ricercatori di sicurezza hanno documentato una serie di attacchi di prompt injection indiretta, in cui istruzioni malevole vengono nascoste in pagine web, metadati o contenuti che un agente AI legge nel corso del proprio lavoro: l’agente, che non distingue in modo affidabile tra un’istruzione del proprio proprietario e un testo qualunque che sta processando, finisce per eseguire il comando nascosto come se fosse legittimo. Il problema di fondo, per come lo hanno descritto pi\u00f9 volte i ricercatori del settore, \u00e8 strutturale: un modello linguistico non separa in modo affidabile \u00abistruzione\u00bb da \u00abdato\u00bb, e finch\u00e9 resta cos\u00ec, ogni agente con accesso a un wallet resta un bersaglio.<\/p> Il settore degli agenti AI on-chain ha gi\u00e0 vissuto una traiettoria simile su un altro fronte, quello della fiducia negli operatori piuttosto che nel codice sottostante: il fondo ai16z<\/a>, poi rinominato ElizaOS, \u00e8 passato da una capitalizzazione miliardaria a poche centinaia di migliaia di dollari nel giro di mesi, con una causa legale degli investitori tuttora in corso. La lezione, applicata al calcolo invece che alla governance del token, \u00e8 la stessa: un framework tecnicamente valido non basta a garantire che l’esecuzione sottostante sia quella dichiarata, se non esiste un modo indipendente per controllarla.<\/p> Il verifiable compute prova a spostare il baricentro della fiducia: invece di fidarsi dell’operatore, del provider cloud o del framework, si verifica la prova matematica, crittografica o economica allegata al risultato. Le quattro strade percorse finora dal settore per arrivarci sono lo zkML, i Trusted Execution Environment (TEE), l’opML e l’approccio crypto-economico basato su stake e slashing.<\/p> Ognuno dei quattro approcci sposta la fiducia su un fondamento diverso: la matematica, l’hardware, gli incentivi economici o un meccanismo di contestazione con una finestra temporale. Nessuno dei quattro \u00e8 oggi universalmente superiore agli altri; ognuno scambia qualcosa, velocit\u00e0, costo o grado di decentralizzazione, per qualcos’altro.<\/p>Cos’\u00e8 il verifiable compute: la definizione<\/h2>
Il problema di fiducia: agenti AI e il caso Grok\/Bankr<\/h2>
Quattro strade per verificare un calcolo<\/h2>