Ogni volta che un modello di intelligenza artificiale produce un risultato, chi lo riceve deve fidarsi di chi lo ha eseguito. Che si tratti di un oracolo che alimenta un protocollo DeFi, di un agente autonomo che firma una transazione o di un sistema di scoring che approva un prestito, l’output arriva come una scatola nera: nessuna garanzia che il modello dichiarato abbia davvero girato sull’input dichiarato, e che qualcuno non lo abbia sostituito lungo il percorso con una versione pi\u00f9 economica. Lo zk-ML, cio\u00e8 il machine learning a conoscenza zero, propone di sostituire quella fiducia con una prova matematica. Per anni \u00e8 rimasto una promessa teorica, troppo costosa per qualunque modello serio. Nel 2026 il quadro \u00e8 cambiato, e vale la pena capire perch\u00e9.<\/p>
Lo zk-ML (zero-knowledge machine learning) \u00e8 l’applicazione delle prove a conoscenza zero al calcolo di un modello di machine learning. L’idea di base \u00e8 semplice da enunciare e difficile da realizzare: chi esegue il modello (il prover<\/em>) genera, insieme al risultato, una prova crittografica che attesta una frase precisa, cio\u00e8 \u00abho eseguito questo specifico modello su questo specifico input e ho ottenuto questo output\u00bb. Chiunque riceva il risultato (il verifier<\/em>) pu\u00f2 controllare quella prova in millisecondi, senza rieseguire il modello e, se serve, senza vedere n\u00e9 i pesi n\u00e9 i dati di ingresso.<\/p> Due propriet\u00e0 rendono la cosa interessante. La prima \u00e8 la succintezza<\/strong>: la prova \u00e8 piccola e si verifica in modo economico, molto pi\u00f9 economico che rieseguire l’inferenza, al punto che il controllo pu\u00f2 avvenire perfino dentro uno smart contract on-chain. La seconda \u00e8 la conoscenza zero<\/strong> vera e propria: la prova pu\u00f2 convincere il verificatore che il calcolo \u00e8 corretto senza rivelare informazioni riservate, come i pesi proprietari del modello o i dati sensibili dell’utente. In pratica, ogni inferenza riceve una ricevuta crittografica che chiunque pu\u00f2 controllare ma che nessuno pu\u00f2 falsificare.<\/p> Il cambiamento di fondo \u00e8 nel modello di fiducia. Oggi, quando un’API vi restituisce l’output di un modello, l’unica opzione \u00e8 fidarsi del fornitore: che abbia usato il modello giusto, che non lo abbia rimpiazzato con uno pi\u00f9 leggero, che non abbia manomesso l’input. Lo zk-ML sposta il baricentro da \u00abfidati del server\u00bb a \u00abverifica la prova\u00bb. \u00c8 lo stesso salto concettuale che le prove a conoscenza zero hanno gi\u00e0 portato allo scaling di Ethereum con i rollup, applicato per\u00f2 a un oggetto molto pi\u00f9 ostile alla crittografia: una rete neurale.<\/p> Il nodo lo ha descritto bene Vitalik Buterin nel suo saggio del gennaio 2024 su crypto e intelligenza artificiale. Se un modello che svolge un ruolo chiave in un meccanismo \u00e8 chiuso, spiega, \u00abnon puoi verificarne il funzionamento interno, e quindi non \u00e8 meglio di un’applicazione centralizzata; se invece il modello \u00e8 aperto, un attaccante pu\u00f2 scaricarlo e simularlo localmente\u00bb<\/a>. \u00c8 un dilemma apparentemente senza uscita: o ti fidi di una scatola nera, o esponi il modello a chi vuole ingannarlo. Le prove a conoscenza zero offrono una terza via, perch\u00e9 permettono di dimostrare che un calcolo \u00e8 avvenuto correttamente senza dover aprire la scatola.<\/p> Qui \u00e8 utile una distinzione che spesso si perde. Reti come Akash, Render o le subnet di Bittensor<\/a> decentralizzano il calcolo<\/em>: affittano GPU sparse nel mondo per eseguire modelli. Ma affittare potenza di calcolo non dice nulla sull’onest\u00e0 del risultato. Un nodo pu\u00f2 restituire l’output di un modello diverso, pi\u00f9 piccolo e pi\u00f9 economico, e in assenza di controlli nessuno se ne accorge. Lo zk-ML non decentralizza il calcolo, ne certifica la correttezza. \u00c8 il tassello che manca alla maggior parte dell’infrastruttura di AI decentralizzata, ed \u00e8 la ragione per cui \u00e8 considerato il cuore del verifiable compute.<\/p> Per capire perch\u00e9 lo zk-ML \u00e8 difficile bisogna guardare a come funziona una prova a conoscenza zero. Un sistema SNARK o STARK non ragiona in termini di codice: traduce il calcolo in un circuito aritmetico<\/strong>, cio\u00e8 in una lunga sequenza di addizioni e moltiplicazioni definite su un campo finito (l’aritmetica modulare degli interi, non i numeri reali). Ogni operazione del modello deve essere riscritta in quella forma. Il prover impegna (commit) i valori intermedi tramite polinomi e produce una prova che tutte le relazioni del circuito sono soddisfatte; il verificatore controlla quella prova con pochi calcoli, senza mai rivedere l’intera computazione.<\/p> La conseguenza pratica \u00e8 un’asimmetria enorme: generare la prova \u00e8 costoso, verificarla \u00e8 quasi gratis. \u00c8 la stessa asimmetria che rende i rollup a conoscenza zero utili per Ethereum, dove una prova compatta riassume migliaia di transazioni e la rete la controlla in una frazione del tempo che servirebbe per rieseguirle. Buterin la riassume notando che una parte della matematica delle reti neurali si presta bene, e una parte malissimo. Le moltiplicazioni tra matrici, che sono il grosso del lavoro di un modello, si possono mettere in una SNARK con \u00abun overhead inferiore a 4x\u00bb<\/a>. Il problema, come vedremo, sono le funzioni non lineari.<\/p> Vale la pena chiarire un punto che spesso genera confusione. \u00abA conoscenza zero\u00bb non significa necessariamente che qualcosa resti nascosto: nel gergo tecnico indica soprattutto la succintezza, cio\u00e8 il fatto che la verifica costi molto meno dell’esecuzione. I sistemi SNARK producono prove piccolissime, ma alcuni richiedono una fase di configurazione iniziale delicata; i sistemi STARK rinunciano a quella fase e restano trasparenti, a costo di prove un po’ pi\u00f9 grandi. Per lo zk-ML la scelta tra le due famiglie incide su tempi, dimensioni e su quanto \u00e8 facile verificare la prova dentro uno smart contract, ma il principio resta lo stesso: dimostrare molto, controllare in poco.<\/p> Messa a terra, la produzione di una prova zk-ML segue una sequenza abbastanza standard, che aiuta a capire dove si concentrano i costi.<\/p> Tutto lo sforzo di ricerca degli ultimi anni si \u00e8 concentrato sui passaggi due e quattro. Ed \u00e8 proprio l\u00ec che nel 2026 sono arrivati i progressi decisivi.<\/p> Una rete neurale non \u00e8 fatta solo di moltiplicazioni. Tra uno strato e l’altro applica funzioni di attivazione non lineari, come ReLU, softmax o GELU, che decidono quali segnali passano e con quale intensit\u00e0. Sono operazioni banali su una GPU, ma un incubo per un circuito aritmetico: richiedono confronti, esponenziali, divisioni, tutte cose che il linguaggio nativo delle SNARK (somma e moltiplicazione su interi) non sa esprimere in modo diretto. Buterin stima che, per gli strati non lineari, \u00able migliori implementazioni pratiche mostrano un overhead intorno a 200x\u00bb<\/a>. Da qui il collo di bottiglia storico.<\/p> C’\u00e8 poi il problema dei numeri. Le reti neurali lavorano in virgola mobile (i float a 32 bit), mentre i circuiti a conoscenza zero vivono nel mondo degli interi su campi finiti. Per far entrare un modello in una SNARK bisogna quantizzarlo<\/strong>, cio\u00e8 approssimarlo con interi a precisione ridotta, spesso a 8 bit. \u00c8 un compromesso a doppio taglio: pi\u00f9 si comprime, pi\u00f9 la prova diventa gestibile, ma pi\u00f9 il modello quantizzato si allontana da quello originale, con perdite di accuratezza che in certi contesti non sono accettabili.<\/p> Il risultato \u00e8 che, fino a poco fa, lo zk-ML riusciva a coprire solo modelli giocattolo. Il progetto Modulus Labs, con il suo studio \u00abThe Cost of Intelligence\u00bb, fu tra i primi a quantificare quanto fosse proibitivo dimostrare inferenze non banali. E gli strumenti che pure avevano reso lo zk-ML accessibile restavano lenti: nei benchmark del 2025 una libreria come EZKL impiegava ancora diversi secondi per un semplice modello di classificazione, contro le frazioni di secondo dei sistemi pi\u00f9 recenti (dati di ICME Labs<\/a>). Con questi ordini di grandezza, l’idea di dimostrare un modello linguistico intero sembrava fuori portata.<\/p> La novit\u00e0 che ha cambiato le carte in tavola si chiama lookup argument<\/strong>. L’intuizione \u00e8 elegante: invece di ricostruire una funzione non lineare come ReLU o softmax con centinaia di porte aritmetiche, la si precalcola in una tabella di corrispondenze ingresso-uscita e si dimostra, in modo compatto, che ogni valore usato appartiene davvero a quella tabella. Le funzioni che facevano esplodere i circuiti diventano, di colpo, quasi gratuite. Come sintetizza Wyatt Benno di ICME Labs, \u00abi lookup eliminano del tutto la necessit\u00e0 di rappresentare la funzione come circuito\u00bb<\/a>.<\/p> Il progetto che incarna meglio questa svolta \u00e8 Jolt Atlas<\/strong>. Jolt \u00e8 un sistema di prova nato in casa a16z Crypto, costruito attorno all’idea di sostituire l’aritmetica pesante con i lookup e con il protocollo sumcheck; ICME Labs (il team dietro la rete NovaNet) lo ha adattato al machine learning, sostituendo il set di istruzioni RISC-V con ONNX<\/strong>, cio\u00e8 il formato in cui i modelli di AI vengono effettivamente esportati (repository su GitHub<\/a>). Il paper che lo descrive \u00e8 uscito a inizio 2026 (arXiv 2602.17452<\/a>). Nei benchmark pubblicati, un modello di classificazione multipla viene dimostrato in circa 0,7 secondi con l’approccio a lookup, contro i 4-5 secondi di EZKL, la libreria che era stata a lungo il riferimento del settore.<\/p> C’\u00e8 un dettaglio che va oltre la pura velocit\u00e0. Grazie agli schemi di folding, che comprimono ricorsivamente le prove, questi sistemi possono girare su hardware modesto: un browser, un telefono, un nodo DePIN. La prova non deve pi\u00f9 passare per un data center dedicato. \u00c8 il tipo di cambiamento che trasforma una curiosit\u00e0 accademica in qualcosa che uno sviluppatore pu\u00f2 integrare in un’app reale, e che sposta lo zk-ML dal laboratorio al prodotto.<\/p> C’\u00e8 una ragione pi\u00f9 profonda per cui i lookup si sposano bene con il machine learning. I carichi di lavoro di una rete neurale hanno schemi molto regolari: le stesse funzioni di attivazione si ripetono milioni di volte, e le tabelle possono essere condivise tra tutte quelle occorrenze invece di essere ricostruite ogni volta. Ci\u00f2 che affossava gli approcci a circuito, la densit\u00e0 delle non linearit\u00e0, diventa un vantaggio per un sistema pensato attorno ai lookup. Non \u00e8 un caso che i benchmark del 2026 mostrino il margine pi\u00f9 ampio proprio sui modelli con molte attivazioni, quelli che in passato erano i pi\u00f9 ostili alla dimostrazione.<\/p> Se i lookup hanno abbattuto il costo dei circuiti, \u00e8 stato Lagrange a piantare la bandiera sul traguardo simbolico. A giugno 2026 il team ha reso open source DeepProve<\/strong>, definendolo il primo sistema zk-ML di livello produttivo, e con DeepProve-1 ha annunciato la prima prova a conoscenza zero di un’inferenza completa di un modello linguistico<\/a>: GPT-2, dimostrato end-to-end. Non \u00e8 il solo modello: secondo il comunicato di rilascio, DeepProve ha dimostrato in modo completo anche Gemma-3, oltre a classificatori e modelli di visione, e ha gi\u00e0 generato oltre 12 milioni di prove crittografiche e verificato pi\u00f9 di 3 milioni di inferenze end-to-end<\/a>.<\/p> I numeri di efficienza raccontano il salto: DeepProve genera le prove degli LLM fino a 60 volte pi\u00f9 velocemente rispetto allo stato dell’arte precedente e le verifica 671 volte pi\u00f9 in fretta, mantenendo intatta l’accuratezza del modello. Supporta nativamente i formati in cui i modelli vengono davvero distribuiti (ONNX, safetensors, GGUF), il che significa che un modello addestrato con PyTorch o scaricato da Hugging Face pu\u00f2 passare per il sistema senza riscritture. Il CEO Ismael Hishon-Rezaizadeh ha inquadrato la mossa open source in modo netto: \u00abNon abbiamo costruito DeepProve per possedere l’AI verificabile. L’abbiamo costruito perch\u00e9 nessuno dovesse farlo\u00bb<\/a>.<\/p> Qui serve per\u00f2 onest\u00e0 tecnica, per non trasformare un traguardo in un’illusione. GPT-2 e Gemma-3 sono modelli piccoli per gli standard del 2026; i modelli di frontiera con decine o centinaia di miliardi di parametri restano fuori portata per una prova a conoscenza zero in tempo reale, e i modelli in classe Llama, come dichiara la stessa Lagrange, sono ancora in sviluppo. Il muro non \u00e8 crollato, si \u00e8 incrinato. La differenza rispetto a due anni fa \u00e8 che ora esiste una traiettoria credibile, non solo una speranza. E la domanda, secondo Lagrange che cita una ricerca McKinsey, c’\u00e8: \u00abil 71% dei dirigenti aziendali dichiara che non scaler\u00e0 i sistemi di AI senza una prova di correttezza\u00bb<\/a>.<\/p> Lo zk-ML non \u00e8 l’unico modo per rendere verificabile un calcolo di AI, ed \u00e8 utile vederlo accanto agli altri per capire cosa promette e cosa costa. Gli approcci principali sono quattro, e si differenziano soprattutto per la fonte della fiducia.<\/p>Il problema: fidarsi di un’AI che non puoi ispezionare<\/h2>
Come una prova avvolge un modello di AI<\/h2>
Il ciclo di vita di una prova, passo per passo<\/h2>
Perch\u00e9 lo zk-ML sembrava impossibile<\/h2>
La svolta del 2026: i lookup abbattono il muro<\/h2>
DeepProve e la prima prova di un LLM intero<\/h2>
Dove si colloca: i quattro modi di verificare l’AI<\/h2>