Verificare che un modello di intelligenza artificiale abbia prodotto davvero il risultato che dichiara \u00e8 uno dei problemi pi\u00f9 concreti all’incrocio tra crypto e AI. opML, sigla di optimistic machine learning, \u00e8 stata per due anni la risposta pi\u00f9 pragmatica a quel problema: si pubblica il risultato di un’inferenza calcolata fuori catena, si apre una finestra di tempo in cui chiunque pu\u00f2 contestarlo e, se nessuno lo fa, quel risultato diventa definitivo. Nel 2026, per\u00f2, la domanda \u00e8 cambiata. Non \u00e8 pi\u00f9 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\u00ec che uno smart contract possa chiedere una verifica senza sapere quale tecnologia ci sia sotto.<\/p>
Per opML \u00e8 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\u00e9 una bozza di standard conta pi\u00f9 di quanto sembri e perch\u00e9 un’interfaccia comune non cancella le differenze di fiducia, n\u00e9 la latenza, che restano sotto. \u00c8 anche la storia di una buona idea che si \u00e8 diffusa mentre il token nato per finanziarla \u00e8 diventato quasi illiquido.<\/p>
opML applica all’intelligenza artificiale la stessa logica dei rollup ottimistici che fanno scalare Ethereum. In un rollup ottimistico si d\u00e0 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.<\/p>
La definizione \u00e8 della squadra che ha coniato il termine. Il paper fondativo, opML: Optimistic Machine Learning on Blockchain<\/a> (gennaio 2024), descrive al suo centro un protocollo interattivo di prova di frode esplicitamente modellato sui rollup ottimistici. La promessa \u00e8 di costi bassissimi: non si rif\u00e0 il calcolo per verificarlo, lo si verifica solo se qualcuno lo contesta. \u00c8 l’opposto dell’approccio crittografico, lo zkML, che produce una prova matematica di correttezza nel momento stesso del calcolo, pagando per\u00f2 un costo computazionale molto pi\u00f9 alto.<\/p> 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, \u00e8 stato formalizzato da Truebit (Jason Teutsch e Christian Reitwiessner) nel paper A scalable verification solution for blockchains<\/a>, 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.<\/p> La macchina che lo rende possibile si chiama Fraud Proof Virtual Machine (FPVM). In modalit\u00e0 a fase singola, ogni passo del calcolo viene rieseguito in una VM vincolata: semplice ma lento, perch\u00e9 rinuncia alla GPU. In modalit\u00e0 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<\/a>), questo riduce la complessit\u00e0 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.<\/p> 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\u00e9 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\u00f9 nulla: un risultato falso non contestato diventa definitivo esattamente come uno vero.<\/p> Qui nasce la tensione centrale del disegno. La finestra di sfida \u00e8 insieme la fonte della sicurezza e il suo collo di bottiglia. Pi\u00f9 \u00e8 lunga, pi\u00f9 tempo hanno gli osservatori per accorgersi di una frode; pi\u00f9 \u00e8 corta, prima il risultato \u00e8 utilizzabile da altri contratti, ma minore \u00e8 il margine per contestare. \u00c8 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 \u00e8 spesso incompatibile con il caso d’uso. Conviene tenere a mente questo punto, perch\u00e9 \u00e8 esattamente ci\u00f2 che nessuna interfaccia standard riesce a nascondere.<\/p> 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<\/a> (pull request numero 1771 sul repository degli standard, ancora allo stato di bozza). Il problema che affronta \u00e8 concreto e noioso, il che di solito \u00e8 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.<\/p> 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\u00f2 implementare. Se prende piede, uno smart contract potr\u00e0 cambiare backend di verifica cambiando un indirizzo, come oggi si cambia il token di un pagamento.<\/p> La bozza non \u00e8 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.<\/p>La genealogia: da Truebit al rollup ottimistico<\/h2>
La finestra di sfida \u00e8 tutto<\/h2>
ERC-8274: opML diventa una spina intercambiabile<\/h2>
I cinque backend dietro un’unica verify()<\/h2>