opML nel 2026: quando verificare l’AI diventa un plug-in

Verificare che un modello di intelligenza artificiale abbia prodotto davvero il risultato che dichiara è uno dei problemi più concreti all’incrocio tra crypto e AI. opML, sigla di optimistic machine learning, è stata per due anni la risposta più pragmatica a quel problema: si pubblica il risultato di un’inferenza calcolata fuori catena, si apre una finestra di tempo in cui chiunque può contestarlo e, se nessuno lo fa, quel risultato diventa definitivo. Nel 2026, però, la domanda è cambiata. Non è più quale metodo di verifica vince, ma come si incastrano tutti insieme. Una bozza di standard Ethereum, ERC-8274, prova a dare una risposta: mette zkML, opML, ambienti di esecuzione fidati (TEE), oracoli e reti di staking dietro un’unica funzione verify(), così che uno smart contract possa chiedere una verifica senza sapere quale tecnologia ci sia sotto.

Per opML è un punto di svolta ambiguo. Smette di essere un prodotto da scegliere e diventa uno dei tanti backend intercambiabili dietro una presa standard. Questo articolo spiega come funziona opML dalle fondamenta, perché una bozza di standard conta più di quanto sembri e perché un’interfaccia comune non cancella le differenze di fiducia, né la latenza, che restano sotto. È anche la storia di una buona idea che si è diffusa mentre il token nato per finanziarla è diventato quasi illiquido.

Che cos’è opML, in breve

opML applica all’intelligenza artificiale la stessa logica dei rollup ottimistici che fanno scalare Ethereum. In un rollup ottimistico si dà per buona una transazione e la si considera valida salvo prova contraria; se qualcuno sospetta un errore, lo dimostra con una prova di frode e chi ha barato viene punito. opML sposta questo schema sul calcolo di un modello: un nodo esegue l’inferenza (per esempio fa girare un modello linguistico su un prompt), pubblica on-chain il risultato insieme a un impegno crittografico, un commitment Merkle, sul calcolo svolto, e apre una finestra di sfida. Se entro la finestra nessuno contesta, il risultato viene accettato come corretto.

La definizione è della squadra che ha coniato il termine. Il paper fondativo, opML: Optimistic Machine Learning on Blockchain (gennaio 2024), descrive al suo centro un protocollo interattivo di prova di frode esplicitamente modellato sui rollup ottimistici. La promessa è di costi bassissimi: non si rifà il calcolo per verificarlo, lo si verifica solo se qualcuno lo contesta. È l’opposto dell’approccio crittografico, lo zkML, che produce una prova matematica di correttezza nel momento stesso del calcolo, pagando però un costo computazionale molto più alto.

La genealogia: da Truebit al rollup ottimistico

L’idea non nasce con l’AI, e nemmeno con i rollup. Il meccanismo del gioco di verifica interattiva, in cui due parti in disaccordo restringono passo dopo passo la contesa fino al singolo passaggio di calcolo contestato, è stato formalizzato da Truebit (Jason Teutsch e Christian Reitwiessner) nel paper A scalable verification solution for blockchains, anni prima che i rollup ottimistici lo rendessero popolare per l’esecuzione generica sulla EVM. opML prende quello schema e lo punta specificamente sull’inferenza dei modelli.

La macchina che lo rende possibile si chiama Fraud Proof Virtual Machine (FPVM). In modalità a fase singola, ogni passo del calcolo viene rieseguito in una VM vincolata: semplice ma lento, perché rinuncia alla GPU. In modalità multi-fase, il calcolo non contestato gira in modo nativo (GPU, parallelismo) e la VM entra in gioco solo sul micro-passaggio contestato, dopo che il gioco di bisezione ha individuato esattamente dove le due parti divergono. Secondo la documentazione del progetto (github.com/ora-io/opml), questo riduce la complessità dell’albero di Merkle e accelera di ordini di grandezza rispetto alla fase singola. Lo stesso repository rivendica di far girare un modello da sette miliardi di parametri su un PC senza GPU: un dato autoriportato dal progetto, non verificato in modo indipendente.

La finestra di sfida è tutto

Tutta la sicurezza di opML si regge su una frase: basta un osservatore onesto. Il modello di minaccia assume che almeno un attore, da qualche parte, rifaccia il calcolo, si accorga di un risultato falso e abbia l’incentivo a contestarlo entro la finestra. Finché quell’ipotesi regge, chi prova a pubblicare un risultato sbagliato viene smascherato e perde la posta messa in gioco, lo stake. Quando non regge, opML non garantisce più nulla: un risultato falso non contestato diventa definitivo esattamente come uno vero.

Qui nasce la tensione centrale del disegno. La finestra di sfida è insieme la fonte della sicurezza e il suo collo di bottiglia. Più è lunga, più tempo hanno gli osservatori per accorgersi di una frode; più è corta, prima il risultato è utilizzabile da altri contratti, ma minore è il margine per contestare. È lo stesso compromesso dei rollup ottimistici, dove la finestra di contestazione dura giorni. Per un oracolo di prezzo o per un agente che deve agire in tempo reale, aspettare la fine di una finestra di sfida è spesso incompatibile con il caso d’uso. Conviene tenere a mente questo punto, perché è esattamente ciò che nessuna interfaccia standard riesce a nascondere.

ERC-8274: opML diventa una spina intercambiabile

Il 26 marzo 2026, nel forum degli Ethereum Magicians, un collaboratore con l’handle JimmyShi22 ha aperto la discussione su ERC-8274, AI Inference Proof Verification (pull request numero 1771 sul repository degli standard, ancora allo stato di bozza). Il problema che affronta è concreto e noioso, il che di solito è un buon segno. Oggi ogni rete di verifica (zkML, opML, TEE, oracoli, reti di staking) parla una lingua diversa, e ogni applicazione che vuole consumare un’inferenza verificata deve scrivere un adattatore su misura per ciascun sistema. Con N verificatori e M consumatori si finisce con un incubo di integrazione N per M: decine di adattatori ad hoc, ciascuno fragile a modo suo.

ERC-8274 propone di spezzare quella moltiplicazione con due interfacce. La prima, IProofVerifier, avvolge la logica di un verificatore esistente dietro una sola funzione, verify(inputHash, outputHash, metadata, proofBytes), che restituisce semplicemente vero o falso; il consumatore la chiama senza sapere quale sistema di prova ci sia sotto. La seconda, IVerificationMethod, serve ai contratti che espongono contenuti AI verificabili per dichiarare quale verificatore usano, tramite una funzione getVerifier() e un evento VerifierUpdated. Lo stesso autore paragona l’approccio al transfer() di ERC-20: un’unica firma di funzione, piatta, senza registri centrali, che chiunque può implementare. Se prende piede, uno smart contract potrà cambiare backend di verifica cambiando un indirizzo, come oggi si cambia il token di un pagamento.

I cinque backend dietro un’unica verify()

La bozza non è un esercizio astratto: elenca per nome i backend che dovrebbero stare dietro l’interfaccia, mappando l’intero panorama 2026 della verifica dell’AI. opML vi compare come una riga tra le altre, incarnata da Ora Protocol.

La tassonomia è illuminante di per sé. opML non è messo in cima né in fondo: è una delle cinque modalità, e l’unica rappresentata da un solo progetto. zkML ne elenca tre, il TEE due, l’oracolo due. Per una tecnologia che nel 2024 veniva presentata come la via pragmatica alla verifica dell’AI, finire incasellata come uno slot con un unico fornitore dice molto su come è cambiato il campo in due anni.

L’interfaccia uniforma l’accesso, non la fiducia

C’è però un problema che la bozza stessa fa emergere, ed è il cuore di questo articolo. Un’interfaccia comune uniforma il modo in cui si chiede una verifica, non ciò che quella verifica significa. Un true restituito da un backend zkML è una prova matematica che il calcolo è stato eseguito esattamente così; un true di un TEE dice che un chip Intel o NVIDIA attesta di averlo eseguito, e vale quanto vale la fiducia nel produttore del chip; un true di opML dice soltanto che nessuno ha contestato il risultato entro la finestra, il che dipende dall’esistenza di un osservatore onesto e motivato. Tre true identici nella firma della funzione, tre garanzie profondamente diverse.

Nel thread, un partecipante con l’handle Damonzwicker ha messo il dito proprio qui: lo standard, osserva, uniforma l’accesso a una verifica che resta specifica del sistema, invece di rendere la verifica indipendente dal sistema che l’ha prodotta. La portabilità vera, aggiunge, richiederebbe di poter ricalcolare, confrontare e confermare l’inclusione senza dipendere da registri o interpreti proprietari. È una critica tecnica, ma ha una conseguenza pratica: lo sviluppatore che chiama verify() e legge true rischia di trattare come equivalenti garanzie che equivalenti non sono. È lo stesso equivoco che si annida in ogni prova on-chain di qualcosa di difficile; come abbiamo visto a proposito di World ID e della prova di essere umani, un booleano restituito a un contratto nasconde quasi sempre un modello di fiducia ben più complicato di quanto la sua semplicità lasci intendere.

opML, zkML, TEE e garanzie economiche a confronto

Prima di capire perché lo standard conta, vale la pena fermarsi sulle differenze che la funzione verify() nasconde. Le quattro grandi famiglie di verifica dell’AI sacrificano ciascuna un angolo diverso di quello che un paper recente chiama il trilemma della verificabilità: integrità del calcolo, bassa latenza e basso costo non si possono avere tutti e tre insieme.

Perché zkML, l’approccio crittograficamente più forte, non ha semplicemente vinto? Per il costo. Vitalik Buterin, nel suo saggio su crypto e AI, stima un sovraccarico intorno a 200 volte per i livelli non lineari di una rete neurale e ricorda che generare una prova a conoscenza zero può richiedere ore, laddove verificare un blocco Ethereum richiede centinaia di millisecondi. Elena Burger di a16z aggiunge il dettaglio tecnico che fa più male: le prove a conoscenza zero di oggi non riescono a rappresentare operazioni in virgola mobile a 32 bit nel formato a circuito richiesto senza sovraccarichi enormi, il che costringe a quantizzare i modelli e ad accettare approssimazioni. opML nasce proprio come scorciatoia attorno a questo muro: salta la prova crittografica e la sostituisce con la minaccia economica di una contestazione.

Da ERC-7007 a ERC-8274: lo standard ha lasciato chi lo ha inventato

C’è un’ironia precisa in tutto questo, e riguarda chi ha scritto cosa. opML e la sua casa madre, Ora Protocol (già Hyper Oracle), non sono estranei al lavoro di standardizzazione: anzi, lo hanno iniziato loro. Lo standard ERC-7007, Verifiable AI-Generated Content Token, oggi in stato Final, è stato redatto dai fondatori stessi di Ora (Cathie So, Xiaohang Yu, KD Conway, Lee Ting Ting e Kartin Wong). E dice una cosa rivelatrice: supporta due tipi di prova, le prove di validità e le prove di frode, e precisa che nella pratica zkML e opML sono gli strumenti comunemente impiegati per le une e per le altre. In altre parole, già nello standard scritto dai creatori di opML, opML è una delle due caselle intercambiabili, non la risposta unica.

ERC-8274 porta quella logica un passo oltre, con un cambio di mano significativo: non è scritto dal team di Ora. La standardizzazione del campo si è spostata fuori dall’edificio che aveva inventato uno dei suoi mattoni. È il destino tipico di una buona primitiva: quando funziona, smette di appartenere a chi l’ha pensata e diventa infrastruttura condivisa. Ottimo per Ethereum, molto meno per chi contava di monetizzare opML come prodotto proprietario. Lo stesso schema lo abbiamo già raccontato altrove: con il framework Eliza, dove il token è collassato mentre il codice continuava a diffondersi, la tecnologia sopravvive spesso al veicolo finanziario che doveva pagarla.

Le piattaforme hanno scelto altri default

Uno standard elenca le opzioni; le piattaforme reali scelgono i default. E nel 2026 i default che si vedono in produzione raramente sono opML. La piattaforma di AI decentralizzata 0G ha presentato a marzo la sua Sealed Inference, in cui ogni risposta è firmata dentro un’enclave hardware (Intel TDX, VM confidenziali NVIDIA H100 e H200): un approccio TEE-first, con opML e zkML indicati come in sviluppo attivo, cioè sulla roadmap, non ancora spediti. Chainlink, la più grande rete di oracoli, descrive il suo stack di AI verificabile imperniato sul Chainlink Runtime Environment e sul consenso decentralizzato dei suoi nodi, con una sperimentazione su azioni societarie condotta insieme a decine di istituzioni finanziarie: nessuna menzione di opML. EigenAI, dalla galassia EigenCloud, ha portato in mainnet un’inferenza LLM deterministica a livello di bit che riproduce lo stesso schema di controllo di opML (pubblica, finestra, slashing) ma con garanzia crypto-economica e determinismo risolto.

Il messaggio implicito è coerente: lo schema ottimistico resta valido, ma quando una piattaforma deve scegliere cosa accendere oggi, sceglie quasi sempre il TEE per la latenza o l’oracolo per la componibilità, e lascia opML alla voce sviluppo futuro. Anche nel mondo dell’infrastruttura GPU e dell’AI privata, come nel caso del voto di Render su un gateway per l’AI privata, la discussione ruota più attorno a enclave e calcolo riservato che attorno alle prove di frode.

La latenza non si può avvolgere in un’interfaccia

Torniamo al nodo tecnico. Ammettiamo che ERC-8274 diventi lo standard e che cambiare backend sia davvero facile come cambiare un indirizzo. Resta un fatto che nessuna interfaccia può toccare: la finestra di sfida di opML consuma tempo reale, e quel tempo non si comprime a colpi di astrazione software. È esattamente la critica che muove il paper Optimistic TEE-Rollups (OTR), firmato da Aaron Chan e colleghi: gli approcci ottimistici, scrivono, impongono finestre di contestazione proibitive che impediscono l’interattività in tempo reale. Lo stesso lavoro misura il trilemma della verificabilità e propone un ibrido che rivendica il 99% del throughput centralizzato a circa 0,07 dollari per interrogazione, con una finalità provvisoria sotto il secondo.

Per capire perché conti, basta immaginare un agente che deve eseguire uno scambio quando un oracolo di prezzo verificato gli dà il via libera. Se quel prezzo è coperto da opML, l’agente ha due sole scelte: fidarsi del risultato prima che la finestra si chiuda (e allora la finestra non lo sta proteggendo) oppure aspettare la fine della finestra (e allora il prezzo è vecchio e lo scambio è saltato). Impacchettare questa scelta dietro una verify() non la fa sparire: la nasconde a chi scrive il contratto, il che è perfino peggio. La latenza è una proprietà del modello di fiducia, non dell’API.

Chi guarda davvero? L’economia del watcher

C’è un secondo fatto che sopravvive a ogni astrazione: opML è sicuro solo se qualcuno guarda. E guardare costa. Rieseguire un’inferenza per controllarla ha un prezzo in GPU; contestare una frode richiede capitale in stake e competenza. Se il risultato è quasi sempre onesto, l’osservatore diligente spende risorse per non trovare quasi mai nulla da contestare, mentre chi non controlla risparmia e nella maggior parte dei casi ottiene lo stesso esito. È il classico dilemma del verificatore: l’incentivo a vigilare tende a zero proprio quando il sistema sembra funzionare meglio.

Quanto morde questo problema nella pratica? Una ricognizione on-chain indipendente pubblicata su ownyourmind.ai ha provato a contare l’attività reale dell’oracolo AI di Ora, l’OAO: conta circa 4.600 richieste in tutta la sua storia su Ethereum, con l’ultima risposta registrata intorno ad aprile 2025, a fronte di cifre di marketing che parlano di oltre 180.000 chiamate di inferenza e di 500 nodi; la stessa ricognizione non riesce a riconciliare le due misure e non trova traccia di una prova di frode mai scattata. Va letto con attenzione: l’assenza di contestazioni è compatibile sia con un sistema perfettamente onesto, sia con un sistema che nessuno sta controllando. Dal di fuori, i due casi sono indistinguibili, ed è precisamente questo a rendere impossibile dare per scontata la sicurezza ottimistica. Vale la pena ricordare che perfino i rollup ottimistici più grandi (Arbitrum, Optimism, Base) hanno impiegato anni per rendere le prove di frode permissionless e restano, nel 2026, a uno stadio intermedio con un consiglio di sicurezza come rete di salvataggio.

Il modello chiuso resta un punto cieco

C’è un limite di opML che nessuna standardizzazione risolve, ed è forse il più imbarazzante proprio per i casi d’uso che contano di più. La prova di frode funziona solo se un contestatore può rieseguire in modo indipendente lo stesso calcolo. Questo vale per i modelli a pesi aperti (Llama, i modelli di Stable Diffusion, i modelli open che un nodo può scaricare e far girare), non per le API chiuse. Quando l’OAO di Ora smista una richiesta verso un modello proprietario come GPT-4o, quel risultato non è verificato da opML nello stesso senso: viene semplicemente inoltrato e attestato, perché nessun osservatore esterno possiede i pesi per rifare il calcolo e dimostrare che è sbagliato.

È un problema serio, perché i modelli più capaci che un agente vorrebbe usare sono quasi tutti chiusi. opML offre la sua garanzia più forte dove serve di meno (sui modelli open riproducibili) e la più debole dove servirebbe di più (sui modelli di frontiera). Nessuna funzione verify() può colmare questo divario: può solo nasconderlo dietro lo stesso booleano che restituisce per un modello open. A questo si aggiunge il problema del determinismo: l’inferenza LLM su GPU non è bit-identica tra ambienti diversi, per via del parallelismo e della virgola mobile, e una prova di frode ha bisogno di determinismo per stabilire chi ha ragione. È il buco che progetti come EigenAI, con la loro esecuzione deterministica a livello di bit, rivendicano di aver tappato, e che opML nella sua forma originale lasciava aperto.

La pagella dei token, backend per backend

Se volete una misura brutale di dove è finito il valore, guardate i token dei progetti citati da ERC-8274, uno per backend. È un buon test, perché mette in fila le stesse famiglie che la bozza tratta come intercambiabili. I prezzi qui sotto sono rilevati da CoinGecko il 3 novembre 2026 e sono volatili.

La lettura è impietosa. Il backend oracolo vale miliardi, l’AVS centinaia di milioni, zkML e TEE decine di milioni; il progetto che ha inventato opML vale meno di 100.000 euro, con un volume di scambi intorno a 80 euro al giorno, così sottile che il prezzo è a malapena significativo. Non è un verdetto sulla tecnologia: tutti questi token sono comunque crollati tra il 77% e oltre il 99% dai massimi, mentre l’infrastruttura continua a funzionare. È un verdetto su un’altra cosa: la standardizzazione toglie potere di prezzo. Il valore si accumula su chi gestisce la presa, non su chi ha inventato la spina. Quando Ora raccolse 20 milioni di dollari nel giugno 2024 da Polychain, HF0 e HashKey Capital, il fondatore Kartin Wong disse a CoinDesk di voler aprire lo spazio di progettazione per le dapp di AI. L’ambizione era giusta; la cattura di valore via token, molto meno.

Cosa cambia per l’Italia: Consob, MiCA e la zona grigia

Per un lettore italiano la domanda pratica è: tutto questo è regolamentato? La risposta breve è che l’infrastruttura in sé non lo è, ma i servizi e i token che ci girano attorno sì. In Italia il quadro è disegnato dal decreto che attua MiCA, il D.lgs. 5 settembre 2024, n. 129, che designa Consob per la condotta di mercato e la tutela degli investitori, e Banca d’Italia per gli aspetti prudenziali e per le stablecoin. opML, come protocollo, non rientra in MiCA; vi rientrano invece i prestatori di servizi (CASP) e, caso per caso, i token.

La distinzione che conta davvero è un’altra, e tocca proprio i token di questo settore. MiCA copre gli asset crypto spot e i loro prestatori di servizi; i derivati crypto, invece, restano strumenti finanziari sotto MiFID II, vigilati dal regolatore dei mercati. E qui si apre la zona grigia. Un token di pura utilità, pensato per pagare le chiamate di inferenza, somiglia a un gettone d’uso. Ma Ora ha coltivato anche un’idea più spinta, l’Initial Model Offering, basata sullo standard ERC-7641 (ancora in bozza), il cui stesso abstract dice che il token, in sostanza, incarna delle quote e dà diritto a riscattare una parte proporzionale dei ricavi di un modello. Un gettone che distribuisce ricavi assomiglia molto di più a uno strumento finanziario che a una utility, e in Italia finirebbe sotto lo sguardo di Consob e della logica MiFID II, non sotto la casella più morbida di MiCA. Sono gli stessi colli di bottiglia della compliance per la finanza decentralizzata che qualsiasi progetto di AI on-chain con un token dovrà attraversare.

Negli Stati Uniti il quadro non aiuta a dissipare l’incertezza: l’interpretazione congiunta SEC-CFTC del marzo 2026 ha nominato una lista di asset digitali qualificati come commodity (tra cui Bitcoin, Ether e LINK) ma non dice nulla sui token di infrastruttura per l’AI verificabile, lasciandoli in una zona di valutazione caso per caso secondo i criteri del test di Howey. Per gli investitori italiani la lezione è la stessa di altre scadenze regolamentari attese a Washington: la classificazione di questi token è ancora aperta, e il rischio normativo va messo in conto quanto quello tecnologico.

La parabola di opML nel 2026 si riassume così: l’idea ha vinto, il prodotto no. Il meccanismo ottimistico, pubblicare e contestare, è diventato una delle cinque modalità che uno standard come ERC-8274 mette dietro la stessa funzione, ed è citato negli standard scritti dagli stessi creatori di opML. Ma proprio perché è diventato una primitiva condivisa, ha smesso di essere qualcosa che si compra: è qualcosa che si accende. La finestra di sfida, l’osservatore onesto e il punto cieco sui modelli chiusi restano esattamente dove erano, sotto l’interfaccia pulita. Per chi costruisce, opML è un interruttore utile nei casi d’uso dove il tempo non stringe e il modello è aperto. Per chi specula sul token, è la prova che diffondersi e catturare valore sono due cose diverse.

Domande frequenti

Che cos’è opML in parole semplici?

opML, sigla di optimistic machine learning, è un metodo per verificare on-chain che un calcolo di AI sia corretto senza rifarlo ogni volta. Un nodo pubblica il risultato di un’inferenza e apre una finestra di sfida: se entro quel periodo nessuno dimostra con una prova di frode che il risultato è sbagliato, viene accettato come valido. È lo stesso principio dei rollup ottimistici applicato ai modelli di machine learning.

Qual è la differenza tra opML e zkML?

La differenza sta in quando e come si ottiene la fiducia. zkML produce al momento del calcolo una prova crittografica che il risultato è corretto, trustless ma costosissima da generare sui modelli grandi. opML non produce alcuna prova in anticipo: dà per buono il risultato e si affida a un osservatore onesto che possa contestarlo entro una finestra di tempo. opML è più economico ma introduce latenza e dipende dall’esistenza di qualcuno che vigili.

Che cos’è lo standard ERC-8274?

ERC-8274 è una bozza di standard Ethereum, proposta nel marzo 2026, che definisce un’interfaccia comune per verificare le prove di inferenza AI. Mette dietro un’unica funzione verify() backend diversi come zkML, opML, TEE, oracoli e reti di staking, così che un’applicazione possa chiedere una verifica senza scrivere un adattatore su misura per ciascun sistema. Per opML significa diventare uno dei tanti backend intercambiabili.

opML è ancora usato nel 2026?

La tecnologia è viva, il suo token molto meno. Il meccanismo opML è ormai citato in standard come ERC-7007 ed ERC-8274 e viene offerto come opzione da varie piattaforme, ma in produzione le piattaforme scelgono spesso TEE o oracoli come default. Il token ORA di Ora Protocol, che ha introdotto opML, nel novembre 2026 ha una capitalizzazione inferiore a 100.000 euro e volumi quasi nulli, segno che l’adozione come prodotto non si è mai materializzata.

I token dell’AI verificabile come ORA sono regolamentati in Italia?

L’infrastruttura in sé non è regolamentata, ma i servizi e i token lo sono. In Italia MiCA, attuata dal D.lgs. 129/2024, affida a Consob la condotta di mercato e a Banca d’Italia gli aspetti prudenziali. Un token di pura utilità per pagare le inferenze somiglia a un gettone d’uso, ma un token che distribuisce i ricavi di un modello assomiglia a uno strumento finanziario e ricade nella logica MiFID II vigilata da Consob, non nella casella più morbida di MiCA.

Marcus Okafor segue l’intersezione tra AI e crypto per HOGE Wire.