Nel 2026 l’intelligenza artificiale \u00e8 entrata ovunque nella crypto: oracoli che interrogano un modello linguistico, agenti che firmano transazioni da soli, giochi on-chain che chiamano una rete neurale a ogni mossa. Resta per\u00f2 una domanda scomoda. Come fa una blockchain, che non pu\u00f2 eseguire un modello da miliardi di parametri, a sapere che quel calcolo \u00e8 stato svolto davvero e in modo corretto? L’opML (optimistic machine learning) \u00e8 una delle risposte pi\u00f9 pragmatiche a questo problema. Invece di dimostrare matematicamente ogni singola operazione, come tenta di fare lo zkML, l’opML parte da un presupposto ottimistico: pubblica il risultato, lo d\u00e0 per buono e apre una finestra di tempo in cui chiunque pu\u00f2 contestarlo.<\/p>
Quella finestra \u00e8 il cuore dell’opML ed \u00e8 anche il suo tallone d’Achille. \u00c8 ci\u00f2 che rende il sistema economico e leggero, ma \u00e8 pure ci\u00f2 che lo mette in rotta di collisione con l’ambizione su cui Ora Protocol, il progetto che ha coniato l’opML, ha puntato di pi\u00f9: l’economia degli agenti autonomi, dove un ritardo di minuti o ore mal si concilia con transazioni che devono chiudersi in secondi. Questa guida spiega come funziona l’opML, da dove arriva, chi lo usa e perch\u00e9 nel 2026 la tensione tra sicurezza e velocit\u00e0 ne definisce il futuro.<\/p>
Il problema di fondo \u00e8 quello che gli sviluppatori chiamano calcolo verificabile: produrre un risultato accompagnato da una prova, poco costosa da controllare, che quel risultato sia stato calcolato correttamente. La posta in gioco \u00e8 la fiducia. Se un contratto agisce sulla base di ci\u00f2 che dice un modello, chi garantisce che l’operatore non abbia restituito una risposta a caso, o volutamente distorta, per risparmiare sul calcolo o per manipolare l’esito? Rieseguire il modello direttamente sulla blockchain sarebbe la garanzia perfetta, ma \u00e8 impossibile: costerebbe una fortuna in gas e nessun validatore tiene pronta una GPU per far girare Llama a ogni blocco. Dimostrare tutto in anticipo con la crittografia, la strada dello zkML, \u00e8 fattibile ma sui modelli grandi resta ancora lentissimo e caro.<\/p>
L’opML sceglie una terza via. Un operatore esegue l’inferenza fuori dalla catena su hardware normale, pubblica il risultato insieme a un impegno crittografico (un Merkle commitment) sulla traccia del calcolo e apre una finestra di sfida. Se entro la scadenza nessuno contesta, il risultato \u00e8 considerato definitivo; se qualcuno contesta, una prova di frode stabilisce chi ha ragione e punisce chi ha mentito. Il nome non \u00e8 casuale: l’approccio \u00e8 modellato sulle optimistic rollup, e il paper fondativo, firmato dal team di Hyper Oracle nel gennaio 2024, descrive esplicitamente il metodo come \u00abreminiscent of the optimistic rollup systems\u00bb (arXiv 2401.17555<\/a>). Ottimistico significa proprio questo: si presume l’onest\u00e0 finch\u00e9 non si dimostra il contrario, spostando il costo dal verificare sempre al verificare solo quando serve.<\/p> Per capire perch\u00e9 l’opML funziona cos\u00ec conviene guardare alla sua genealogia. Le optimistic rollup come Arbitrum e OP Stack hanno reso popolare l’idea di dare per validi i risultati e affidarsi a una finestra di contestazione con prove di frode. Ma quel meccanismo \u00e8 pi\u00f9 antico: nasce da Truebit, il progetto di Jason Teutsch e Christian Reitwiessner che introdusse il gioco di verifica interattivo. Invece di rieseguire l’intero calcolo, i contendenti restringono la disputa a un singolo passo tramite bisezione, e solo quel passo minuscolo viene giudicato on-chain. \u00c8 un’idea potente: rende economico arbitrare una disputa su una computazione enorme, perch\u00e9 la catena deve controllare una sola istruzione, non tutte.<\/p> L’opML applica esattamente questa idea al machine learning. Prima ancora del paper accademico, la proposta era comparsa nell’agosto 2023 sul forum di governance di Optimism, segno di quanto il metodo fosse imparentato con il mondo delle rollup. La stessa logica di verifica su nodi non fidati \u00e8 al centro di altri progetti di AI decentralizzata: chi vuole capire come una disputa possa stabilire la correttezza di un calcolo eseguito da attori anonimi pu\u00f2 leggere la nostra analisi su come Gensyn verifica l’AI su nodi non fidati<\/a>. La differenza \u00e8 nel dominio: Truebit puntava all’esecuzione generica, l’opML alla singola inferenza di una rete neurale, con tutte le complicazioni che i modelli AI portano con s\u00e9 (dimensioni enormi, aritmetica in virgola mobile, non determinismo).<\/p> Il ciclo di vita di una richiesta opML si pu\u00f2 riassumere in cinque passaggi. Primo, un submitter (chi sottomette la richiesta) esegue il modello fuori catena su hardware normale. Secondo, pubblica on-chain il risultato e un impegno crittografico sulla traccia completa del calcolo, cio\u00e8 su ogni stato intermedio della computazione. Terzo, si apre la finestra di sfida, un intervallo di tempo prefissato. Quarto, se nessun osservatore contesta entro la scadenza, il risultato diventa definitivo e viene restituito al contratto che lo aveva richiesto. Quinto, se un osservatore rileva un errore, avvia una prova di frode e il protocollo stabilisce chi dice il vero, punendo la parte disonesta.<\/p> Attorno a questo flusso ruotano tre attori con incentivi diversi: il richiedente, che paga per una risposta affidabile; il submitter, che di norma deposita una cauzione a garanzia della propria onest\u00e0; e uno o pi\u00f9 osservatori, che rifanno i conti e possono guadagnare contestando un risultato falso, incassando in tutto o in parte la cauzione del bugiardo. \u00c8 un sistema a incentivi, non una dimostrazione matematica: funziona finch\u00e9 contestare conviene e finch\u00e9 c’\u00e8 qualcuno disposto a farlo.<\/p> Il modello di sicurezza si regge infatti su un presupposto preciso: basta almeno un osservatore onesto (una assunzione detta one-of-N) che rifaccia il calcolo e sia pronto a contestare. Finch\u00e9 esiste anche un solo watcher vigile e capace, un risultato falso viene smascherato. Ed \u00e8 qui che la finestra di sfida rivela la sua doppia natura: \u00e8 la fonte di tutta la sicurezza del sistema, ma \u00e8 anche la sua latenza incorporata. Una finestra lunga d\u00e0 pi\u00f9 tempo agli osservatori e rende il sistema pi\u00f9 sicuro; una finestra corta rende l’opML pi\u00f9 veloce ma lascia meno margine per scoprire una frode. Ogni scelta sulla durata della finestra \u00e8 un compromesso diretto tra fiducia e velocit\u00e0, e questo compromesso, come vedremo, \u00e8 il nodo dell’intera storia.<\/p> Il motore tecnico dell’opML \u00e8 la Fraud Proof Virtual Machine (FPVM), una macchina virtuale deterministica in cui il calcolo contestato pu\u00f2 essere rieseguito passo per passo. Il paper originale descrive due modalit\u00e0. Nella versione a fase singola, ogni operazione del modello viene rieseguita dentro la VM vincolata: semplice e robusta, ma lenta, perch\u00e9 rinuncia alla GPU. Nella versione multifase, la computazione non contestata gira in modo nativo e parallelo (GPU inclusa) e solo il micro-passo su cui verte la disputa, individuato tramite bisezione interattiva, finisce nella VM. Il team sostiene che questo riduca la complessit\u00e0 dell’albero di Merkle da O(mn) a O(m+n), con un’accelerazione \u00abda decine a centinaia di volte\u00bb rispetto alla fase singola (github.com\/ora-io\/opml<\/a>).<\/p> La bisezione merita un esempio. Immaginate che submitter e challenger siano d’accordo sullo stato iniziale del calcolo ma non su quello finale. Il protocollo chiede a entrambi lo stato a met\u00e0 strada: se coincide, l’errore \u00e8 nella seconda met\u00e0; se differisce, \u00e8 nella prima. Ripetendo la domanda si dimezza ogni volta l’intervallo, finch\u00e9 resta un solo passo di calcolo su cui i due divergono. Quel singolo passo, e solo quello, viene eseguito on-chain nella FPVM per decretare chi ha ragione. \u00c8 una ricerca binaria sulla computazione, ed \u00e8 ci\u00f2 che rende sostenibile arbitrare on-chain una disputa su un modello enorme.<\/p> I benchmark diffusi dal progetto sono su scala ridotta e vanno letti come dati interni, non verificati in modo indipendente: su una rete di test locale e su un modello di tipo MNIST si parla di circa due secondi per l’inferenza e circa due minuti per l’intero ciclo di sfida; viene inoltre rivendicata l’esecuzione di un modello LLaMA da 7 miliardi di parametri (circa 26 GB) su un PC standard senza GPU. Il dettaglio cruciale \u00e8 un altro: la bisezione funziona solo se la riesecuzione \u00e8 bit-identica. Se due esecuzioni oneste dello stesso modello producono output leggermente diversi, il gioco di verifica non sa pi\u00f9 chi ha ragione. \u00c8 il motivo per cui l’opML si appoggia a una VM deterministica e priva di GPU, e anticipa uno dei suoi problemi pi\u00f9 sottili, il determinismo, su cui torneremo.<\/p> L’opML \u00e8 indissolubilmente legato a Ora Protocol, il progetto che lo ha inventato. Nato nel settembre 2022 come Hyper Oracle, un oracolo basato su prove zero-knowledge (uno zkOracle), \u00e8 stato fondato da Kartin Wong, con un passato nell’infrastruttura di Google e TikTok; tra le figure chiave c’\u00e8 Cathie So, ricercatrice zkML proveniente dal gruppo PSE della Ethereum Foundation. Questa doppia anima, zkML e opML nella stessa squadra, spiega perch\u00e9 Ora oggi tratti i due approcci come strumenti complementari e non come rivali. Nel giugno 2024 la societ\u00e0 ha raccolto 20 milioni di dollari da Polychain, HF0 e HashKey Capital.<\/p> In quell’occasione Wong ha dichiarato a CoinDesk<\/a> di voler \u00abunlock the design space for AI dapps\u00bb, con fondi destinati a \u00abtokenizing AI models and bringing decentralized AI to the Ethereum ecosystem\u00bb. Il prodotto di punta \u00e8 OAO (Onchain AI Oracle), un sistema di contratti protetti dall’opML e distribuiti con lo stesso indirizzo su oltre una dozzina di reti, da Ethereum a Optimism, Arbitrum, Base e Polygon. Il flusso \u00e8 lineare: un contratto invia una richiesta, i nodi opML la eseguono, il risultato viene pubblicato con la sua finestra di sfida e infine restituito via callback al richiedente.<\/p> OAO supporta modelli a pesi aperti come Llama 3.3 da 70 miliardi di parametri, Qwen, Mistral e Gemma, generatori di immagini come Stable Diffusion e FLUX, oltre ad API proprietarie come GPT-4o, con tariffe comprese tra 0,01 e 1,00 ORA per chiamata (github.com\/ora-io\/OAO<\/a>). Ora ha anche introdotto le Initial Model Offering (IMO), token che rappresentano una quota dei ricavi di un modello, con $OLM come primo esperimento; \u00e8 un tema apparentemente marginale ma con implicazioni normative pesanti, su cui torneremo nell’ultima sezione.<\/p> L’applicazione su cui Ora ha scommesso di pi\u00f9 \u00e8 opAgent, presentata dalla societ\u00e0 come un framework per \u00abOnchain Perpetual Agent\u00bb e attiva dal 31 gennaio 2025 (Decrypt<\/a>). L’idea \u00e8 ambiziosa: agenti che, secondo la societ\u00e0, \u00abexist indefinitely through the blockchain\u00bb, controllati dalla logica di uno smart contract e non da una chiave privata, capaci di \u00abmaintain permanent ownership of digital assets, operate through verifiable computations, and evolve through mathematical consensus\u00bb. In questo disegno l’opML \u00e8 il ponte che rende verificabile ogni singola azione dell’agente, dal trade su un DEX al trasferimento di token. opAgent \u00e8 arrivato insieme a RMS (Resilient Model Services), e pi\u00f9 di recente Ora ha aggiunto Pump.ai per la creazione permissionless di agenti, con deployment che si estendono anche a Solana e Hyperliquid.<\/p> Il fatto che un agente sia governato da uno smart contract e non da una chiave privata \u00e8, sulla carta, una promessa di sicurezza notevole: niente seed phrase da rubare, niente wallet compromesso che svuota il tesoro dell’agente. La societ\u00e0 lo vende proprio cos\u00ec, come un modo per eliminare le vulnerabilit\u00e0 legate alle chiavi tradizionali. Ma sposta il problema, non lo cancella: se le azioni dell’agente derivano dall’output di un modello, la sicurezza dell’intero sistema dipende dalla verifica di quell’output, cio\u00e8 dall’opML e dalla sua finestra.<\/p> Qui si annida la tensione centrale di questa guida. Un agente autonomo che gestisce capitale ha senso solo se le sue azioni sono affidabili, e l’opML promette proprio quell’affidabilit\u00e0. Ma un agente utile deve anche agire in fretta, reagire al mercato, concatenare operazioni. E ogni azione verificata dall’opML deve attraversare la finestra di sfida prima di essere davvero definitiva. La stessa propriet\u00e0 che rende l’agente credibile lo rallenta. Per un confronto con l’altro grande filone di software per agenti, quello dei framework general purpose, si veda la nostra analisi di Eliza come sistema operativo per agenti e gaming<\/a>.<\/p> Prima di valutare la collisione conviene guardare quanto \u00e8 reale, oggi, l’economia degli agenti. Il protocollo di pagamento pi\u00f9 citato \u00e8 x402 di Coinbase, che resuscita il vecchio codice HTTP 402 (Payment Required) per far pagare gli agenti a ogni richiesta, in USDC e senza approvazione umana. \u00c8 l’idraulica perfetta per un mondo di macchine che comprano servizi da altre macchine. I numeri, per\u00f2, raccontano una storia pi\u00f9 sobria. Un’analisi di TRM Labs ripresa da PYMNTS<\/a> ha esaminato 52,7 milioni di dollari di valore su 198,9 milioni di transazioni di regolamento x402 tra Base, Solana e Polygon da maggio 2025: dopo aver filtrato l’attivit\u00e0 non commerciale, \u00abjust 0.6% to 7.5% of the remaining payment value appeared to be agentic\u00bb. Il resto \u00e8 automazione ordinaria, script che avrebbero potuto girare senza alcuna AI.<\/p> Due dati di quell’analisi contano per l’opML. Il primo \u00e8 che l’economia degli agenti, oggi, \u00e8 pi\u00f9 infrastruttura che adozione: si costruiscono le tubature prima che arrivi l’acqua. \u00c8 lo stesso scarto tra promessa e utilizzo che, come vedremo, colpisce anche l’opML. Il secondo \u00e8 che il 99,6% del valore regolato viaggiava in USDC su reti scelte proprio per commissioni basse e finalit\u00e0 rapida.<\/p> In altre parole, il caso d’uso che dovrebbe trainare l’opML premia la velocit\u00e0 di regolamento, esattamente la propriet\u00e0 che una finestra di sfida non pu\u00f2 offrire. \u00c8 un contrasto che vale la pena tenere a mente: la domanda a cui l’opML vuole rispondere pretende una cosa che l’opML, per costruzione, fatica a dare. Se gli agenti si moltiplicheranno davvero, lo faranno su binari che chiedono conferme in millisecondi, non finestre di contestazione da minuti.<\/p> Arriviamo al punto. La sicurezza dell’opML, cio\u00e8 la finestra di sfida, \u00e8 strutturalmente in contrasto con le esigenze di tempo reale e componibilit\u00e0 dell’economia degli agenti. Non \u00e8 una critica di parte: \u00e8 la tesi centrale del paper \u00abOptimistic TEE-Rollups\u00bb (arXiv 2512.20176<\/a>), che scrive senza mezzi termini che gli approcci ottimistici \u00abimpose prohibitive dispute windows, preventing real-time interactivity\u00bb. Gli stessi autori inquadrano il problema in un trilemma della verificabilit\u00e0: un sistema di inferenza decentralizzata \u00abcannot simultaneously achieve\u00bb integrit\u00e0 computazionale alta, latenza bassa e costo basso. Si possono avere due propriet\u00e0 su tre; l’opML sceglie integrit\u00e0 e costo, e paga in latenza.<\/p> Il problema si aggrava in due modi. Il primo \u00e8 la distinzione tra finalit\u00e0 debole e finalit\u00e0 forte: subito dopo la pubblicazione un risultato opML \u00e8 provvisorio, e diventa davvero irreversibile solo alla chiusura della finestra. Un agente che agisce sulla finalit\u00e0 debole si espone a un ribaltamento; uno che aspetta la finalit\u00e0 forte \u00e8 lento. Il secondo \u00e8 la componibilit\u00e0: se l’agente B dipende dall’output dell’agente A, deve attendere la finestra di A prima di poter chiudere la propria, e una catena di dipendenze moltiplica l’attesa. In un ecosistema in cui i protocolli si chiamano a vicenda di continuo, questo effetto a cascata \u00e8 tutt’altro che teorico.<\/p> Un esempio concreto rende l’idea. Un agente legge un modello per decidere un trade: la risposta del modello arriva in pochi secondi, ma il trade non pu\u00f2 considerarsi sicuro finch\u00e9 la finestra (da minuti a ore) non si chiude. L’agente ha due scelte, entrambe scomode: agire subito rischiando che quel risultato venga poi contestato e rovesciato, oppure aspettare e rinunciare all’opportunit\u00e0 che voleva cogliere. Non a caso l’architettura ibrida proposta dagli autori dell’OTR rivendica una finalit\u00e0 provvisoria sub-secondo, il 99% del throughput di un sistema centralizzato e un costo di circa 0,07 dollari per query, con un’accelerazione fino a 1.400 volte rispetto allo zkML puro: tutto il senso di quel lavoro \u00e8 aggirare proprio il collo di bottiglia della finestra opML. Quando la soluzione a un problema \u00e8 progettata per eliminarne il tratto distintivo, \u00e8 un segnale che quel tratto \u00e8 diventato un costo.<\/p> C’\u00e8 una seconda crepa, pi\u00f9 silenziosa. L’opML \u00e8 sicuro finch\u00e9 esiste almeno un osservatore onesto che rif\u00e0 i conti. Ma chi paga quell’osservatore per vigilare? Rieseguire un’inferenza costa tempo e potenza di calcolo, mentre la ricompensa (scoprire una frode rara) \u00e8 incerta e sporadica. \u00c8 il classico dilemma del verificatore: se ognuno confida che qualcun altro stia controllando, alla fine non controlla nessuno, perch\u00e9 per il singolo attore razionale il costo del controllo supera il beneficio atteso. Truebit aveva affrontato il problema con un meccanismo di errori forzati e un jackpot che teneva desti i verificatori; l’opML, allo stato, non ha una soluzione altrettanto rodata e distribuita.<\/p> Ne discende una domanda che nessuno ha ancora chiuso pubblicamente: una prova di frode \u00e8 mai scattata davvero su OAO? Le richieste al sistema sono pubbliche e tracciabili, ma non risulta divulgato alcun episodio di contestazione andata a buon fine, n\u00e9 numeri di utilizzo che facciano pensare a un mercato di osservatori vivo e competitivo. In assenza di quei dati, \u00e8 ragionevole sospettare che, nella pratica, la garanzia poggi pi\u00f9 sulla buona fede dei nodi gestiti da Ora che su una platea di watcher indipendenti in perenne allerta. \u00c8 esattamente quando la pressione sulla velocit\u00e0 spinge ad accorciare le finestre che questa fragilit\u00e0 diventa pi\u00f9 preoccupante: meno tempo per contestare significa che l’ipotesi one-of-N deve reggere in una manciata di secondi, con incentivi ancora tutti da costruire.<\/p> Tre limiti strutturali completano il quadro. Il primo \u00e8 il buco dei modelli chiusi. La prova di frode dell’opML ha senso solo se un contestatore pu\u00f2 rieseguire in modo indipendente il calcolo, e questo richiede pesi aperti come Llama o Stable Diffusion. Le API proprietarie come GPT-4o possono essere inoltrate e attestate, ma non verificate dall’opML nello stesso senso: nessun osservatore ha i pesi per rifare il conto. \u00c8 un problema serio per gli agenti, perch\u00e9 i modelli migliori sono spesso chiusi, e cos\u00ec proprio dove servirebbe pi\u00f9 garanzia l’opML non riesce a darla.<\/p> Il secondo limite \u00e8 la privacy: per essere contestabile, la traccia del calcolo deve essere pubblica, il che rende l’opML incompatibile con input o pesi riservati, a meno di combinarlo con prove zero-knowledge. Il terzo, forse il pi\u00f9 insidioso, \u00e8 il determinismo. La prova di frode funziona rieseguendo il calcolo e confrontando i risultati byte per byte, ma l’inferenza LLM su GPU \u00e8 notoriamente non deterministica, per la non associativit\u00e0 dell’aritmetica in virgola mobile e per il modo in cui variano i batch a seconda del carico. Se due esecuzioni oneste divergono, il gioco di verifica non sa pi\u00f9 chi punire. Non a caso i numeri in virgola mobile a 32 bit sono ostici da rappresentare nei circuiti delle prove crittografiche senza costi enormi, ed \u00e8 la stessa ragione per cui questi sistemi ricorrono alla quantizzazione. Abbiamo dedicato un approfondimento al perch\u00e9 l’AI verificabile ha bisogno del determinismo<\/a>.<\/p> L’opML \u00e8 solo uno dei quattro grandi approcci al calcolo AI verificabile, e si capisce meglio confrontandolo con gli altri tre. Lo zkML dimostra tutto in anticipo con la crittografia (fiducia nella matematica, zero fiducia nell’operatore) al prezzo di un overhead enorme. I TEE (Trusted Execution Environment) si affidano all’attestazione dell’hardware: veloci e a basso overhead, ma bisogna fidarsi del produttore del chip e sperare che non esistano canali laterali. L’approccio crypto-economico (stake e slashing, come in EigenCloud) offre una garanzia economica, non crittografica: attaccare conviene solo se il bottino supera lo stake a rischio. L’opML sta nel mezzo: poco overhead di calcolo, nessuna fiducia nella matematica, ma latenza alta per via della finestra. La regola generale, come nota chi studia il settore, \u00e8 che il calcolo a buon mercato tende a essere non verificabile e quello verificabile tende a costare; ogni approccio \u00e8 un modo diverso di pagare quel conto.<\/p>Dalle optimistic rollup a Truebit: la genealogia dell’opML<\/h2>
Come funziona: la finestra di sfida \u00e8 tutto<\/h2>
Dentro la macchina: FPVM, bisezione e prove di frode<\/h2>
Ora Protocol: da Hyper Oracle all’oracolo AI on-chain<\/h2>
opAgent e la scommessa sugli agenti perpetui<\/h2>
L’economia degli agenti nel 2026: pi\u00f9 infrastruttura che adozione<\/h2>
La collisione: la finestra di sfida contro il tempo reale<\/h2>
Chi controlla davvero? Il dilemma del verificatore<\/h2>
I limiti strutturali: modelli chiusi, privacy e determinismo<\/h2>
opML a confronto: zkML, TEE e crypto-economico<\/h2>