Un modello di intelligenza artificiale \u00e8 una scatola nera. Gli si fornisce un input, restituisce un output, e nel mezzo ci sono miliardi di moltiplicazioni che nessuno, nemmeno chi ha addestrato il modello, riesce a ispezionare a occhio. Per gran parte del software questo non \u00e8 un problema: ci si fida del fornitore. Ma la crypto nasce dal principio opposto, \u00abnon fidarti, verifica\u00bb, e quel principio va in cortocircuito nel momento in cui un contratto intelligente, un oracolo o un agente autonomo deve accettare come vera la risposta di un modello che non pu\u00f2 rieseguire.<\/p>
Lo zk-ML (zero-knowledge machine learning) prova a sciogliere questo nodo. L’idea \u00e8 produrre, insieme al risultato di un’inferenza, una ricevuta crittografica che dimostra due cose: che \u00e8 stato eseguito quel modello preciso e che l’ha eseguito su quegli input, ottenendo esattamente quell’output. Chi verifica non deve rieseguire il calcolo n\u00e9 vedere i pesi del modello: gli basta controllare una prova che si valida in millisecondi.<\/p>
Vale la pena chiarire subito un equivoco. Lo zk-ML non serve a rendere l’AI pi\u00f9 intelligente n\u00e9 a spiegarne le decisioni: non \u00e8 uno strumento di interpretabilit\u00e0. Serve a una cosa sola, ma cruciale in un contesto senza fiducia: garantire che il calcolo dichiarato sia esattamente il calcolo avvenuto. Per anni \u00e8 stato pi\u00f9 una promessa accademica che una tecnologia utilizzabile, perch\u00e9 dimostrare l’inferenza anche di una piccola rete neurale poteva richiedere ore. Nel 2026 qualcosa si \u00e8 mosso davvero, al punto che un LLM intero \u00e8 stato dimostrato dall’inizio alla fine. Questa guida spiega come \u00e8 fatta la macchina che genera quelle prove, dove sbatteva contro il muro e perch\u00e9 adesso quel muro si sta incrinando.<\/p>
Lo zk-ML \u00e8 l’insieme delle tecniche che permettono di dimostrare, con una prova a conoscenza zero, che una specifica inferenza di machine learning \u00e8 stata calcolata correttamente. \u00abA conoscenza zero\u00bb significa che la prova pu\u00f2 nascondere informazioni sensibili (gli input dell’utente, i pesi del modello, o entrambi) rivelando soltanto ci\u00f2 che serve: che il calcolo \u00e8 avvenuto secondo le regole.<\/p>
Conviene separare subito due propriet\u00e0 che spesso vengono confuse. La prima \u00e8 l’integrit\u00e0: la prova certifica che il risultato non \u00e8 stato manomesso e che proviene proprio da quel modello. La seconda \u00e8 la riservatezza: grazie alla componente a conoscenza zero, si pu\u00f2 dimostrare l’integrit\u00e0 senza esporre i dati. Molte applicazioni vogliono solo la prima; altre, come la sanit\u00e0 o la finanza, hanno bisogno anche della seconda. Tenere a mente questa distinzione \u00e8 utile, perch\u00e9 determina quale strumento conviene usare.<\/p>
Vitalik Buterin, in un saggio del 2024<\/a> tornato di grande attualit\u00e0, ha classificato quattro modi di combinare AI e crypto: l’AI come giocatore dentro un meccanismo, come interfaccia verso di esso, come regola del gioco e come obiettivo del gioco. Sul terzo caso, l’AI che diventa la regola (per esempio un modello che decide come si muovono i fondi in un protocollo), la sua indicazione \u00e8 di muoversi con estrema cautela. Il motivo \u00e8 ovvio: se un’AI stabilisce chi viene liquidato o quanto vale un asset, chiunque abbia interesse a barare prover\u00e0 a manipolarla, e senza una prova non c’\u00e8 modo di accorgersene.<\/p> La posta in gioco non \u00e8 teorica. Immaginiamo un protocollo di prestito che usa un modello per stimare la volatilit\u00e0 di un collaterale e decidere il rapporto di sovracollateralizzazione. Se quel modello gira su un server che nessuno pu\u00f2 controllare, chi lo gestisce potrebbe fargli restituire un valore compiacente, aprendo la strada a prestiti sottogarantiti o a liquidazioni ingiuste. Con una prova zk-ML, il contratto accetta l’output solo se accompagnato dalla dimostrazione che \u00e8 stato prodotto proprio da quel modello, su quei dati, senza scorciatoie. La fiducia si sposta dall’operatore alla matematica.<\/p> Gli esempi concreti si moltiplicano. Un agente autonomo che gestisce un fondo<\/a> dovrebbe dimostrare di aver seguito la strategia dichiarata e non un’altra. Un oracolo che pubblica un prezzo derivato da un modello dovrebbe poter provare quale modello ha usato. Un agente costruito su un framework come Eliza<\/a> che firma transazioni per conto di un utente ha bisogno di garanzie verificabili prima che qualcuno gli affidi una chiave. In tutti questi casi la domanda \u00e8 la stessa: come faccio a sapere che l’AI ha calcolato ci\u00f2 che dice di aver calcolato? Lo zk-ML \u00e8 una delle poche risposte che non richiedono di fidarsi di nessuno.<\/p> Nel senso tecnico, una prova a conoscenza zero deve soddisfare tre propriet\u00e0. La completezza: se il calcolo \u00e8 stato fatto onestamente, il verificatore accetter\u00e0 sempre la prova. La solidit\u00e0: se il risultato \u00e8 falso, \u00e8 computazionalmente impossibile produrre una prova che venga accettata, salvo una probabilit\u00e0 trascurabile. La conoscenza zero vera e propria: la prova non rivela nulla oltre alla verit\u00e0 dell’affermazione.<\/p> Applicate all’inferenza di un modello, queste propriet\u00e0 si traducono cos\u00ec. La completezza garantisce che chi ha eseguito il modello onestamente potr\u00e0 sempre convincere la controparte. La solidit\u00e0 impedisce a un nodo disonesto di spacciare per output del modello un numero inventato: la matematica non glielo consente. La conoscenza zero, infine, \u00e8 opzionale ma preziosa: consente a un ospedale di dimostrare che una diagnosi \u00e8 uscita da un modello certificato senza pubblicare la cartella clinica del paziente, o a un’azienda di provare che il suo modello proprietario ha prodotto un certo risultato senza regalare i pesi ai concorrenti.<\/p> Sotto il cofano, le prove pi\u00f9 usate nello zk-ML appartengono a due famiglie: le SNARK (prove succinte e non interattive, molto compatte da verificare) e le STARK (che rinunciano a un setup fidato e reggono meglio la scala, al prezzo di prove pi\u00f9 grandi). Sistemi come Halo2, i vari schemi Plonkish o i protocolli basati sul sumcheck sono i motori concreti che trasformano i vincoli aritmetici in una prova. Per chi costruisce, la scelta del motore determina tempi, dimensione della prova e costo di verifica on-chain; per chi legge, basta sapere che sono strumenti diversi per lo stesso obiettivo: dimostrare un calcolo senza rifarlo. Va aggiunto che \u00abprova di validit\u00e0\u00bb e \u00abprova a conoscenza zero\u00bb non sono sinonimi, anche se nel gergo del settore vengono usati in modo intercambiabile: un sistema pu\u00f2 fornire integrit\u00e0 senza riservatezza oppure entrambe, e la differenza conta quando si progetta un’applicazione reale.<\/p> Per capire dove lo zk-ML diventa difficile, conviene seguire una singola inferenza lungo tutta la catena, dal modello addestrato alla prova che un contratto verifica on-chain. I passaggi sono pi\u00f9 o meno sempre questi.<\/p> Questa asimmetria (prova costosa, verifica economica) \u00e8 il cuore del valore dello zk-ML: sposta tutto il lavoro sul provatore e lascia al verificatore un compito banale. Il problema \u00e8 che le fasi di quantizzazione, aritmetizzazione e generazione nascondono tre ostacoli tecnici che per anni hanno reso lo zk-ML impraticabile su modelli seri. Conviene esaminarli uno per uno.<\/p> Non tutte le operazioni di una rete neurale costano uguale da dimostrare. Le moltiplicazioni di matrici, che costituiscono la parte quantitativamente dominante del calcolo, si prestano bene ai sistemi di prova: Buterin osserva che le migliori implementazioni mostrano un overhead inferiore a 4 volte<\/a> per dimostrare una moltiplicazione di matrici. Il guaio sono le operazioni non lineari: le funzioni di attivazione come ReLU o softmax, i confronti, gli arrotondamenti. Espresse come vincoli aritmetici, queste funzioni diventano sproporzionatamente costose, e lo stesso Buterin nota che l’overhead sui livelli non lineari resta significativo, con le migliori implementazioni pratiche intorno a 200 volte.<\/p> Il paradosso \u00e8 evidente: la parte del modello che pesa di pi\u00f9 nel calcolo grezzo \u00e8 quella facile da dimostrare, mentre le funzioni che occupano una frazione minima del tempo di esecuzione fanno esplodere il costo della prova. Per anni la ricerca sullo zk-ML \u00e8 stata in larga parte una caccia a modi pi\u00f9 intelligenti di aritmetizzare la non linearit\u00e0.<\/p> Il secondo scoglio \u00e8 la rappresentazione dei numeri. I modelli lavorano in virgola mobile, tipicamente a 32 bit, mentre i sistemi di prova ragionano su campi finiti di numeri interi. Tradurre l’una nell’altra non \u00e8 gratis. Elena Burger, deal partner di a16z crypto, lo ha spiegato con chiarezza: \u00abi parametri e le attivazioni dei modelli sono spesso codificati a 32 bit per precisione, ma le prove a conoscenza zero oggi non riescono a rappresentare operazioni in virgola mobile a 32 bit nel formato di circuito aritmetico necessario senza overhead enormi\u00bb<\/a>.<\/p> La soluzione pratica \u00e8 la quantizzazione: si convertono i numeri in interi a 8 bit, molto pi\u00f9 docili per un circuito. Ma qui si paga un prezzo. Come nota la stessa Burger, il modello effettivamente verificato \u00abpotrebbe essere un’approssimazione grossolana del modello iniziale di qualit\u00e0 superiore\u00bb. In altre parole, si dimostra con certezza matematica l’esecuzione di un modello che non \u00e8 esattamente quello di partenza. Per un classificatore di immagini la perdita di accuratezza pu\u00f2 essere accettabile; per applicazioni sensibili \u00e8 un compromesso da valutare con attenzione.<\/p> Il terzo problema \u00e8 semplicemente la dimensione. Pi\u00f9 parametri ha un modello, pi\u00f9 operazioni vanno dimostrate, pi\u00f9 tempo e memoria servono al prover. Con i sistemi di qualche anno fa i numeri erano scoraggianti, e Buterin fotografava bene l’ordine di grandezza: \u00abun blocco Ethereum richiede poche centinaia di millisecondi per essere verificato direttamente, ma generare una ZK-SNARK che ne dimostri la correttezza pu\u00f2 richiedere ore\u00bb<\/a>. Trasportato su una rete neurale, questo significava che dimostrare anche un modello modesto poteva costare ore di calcolo per un singolo esempio. Moltiplicare quel costo per i miliardi di parametri di un LLM equivaleva, in pratica, all’impossibilit\u00e0.<\/p> Non a caso i primi esperimenti seri si concentravano su modelli minuscoli. Modulus Labs, la startup \u00abZK-meets-AI\u00bb che nel 2023 raccolse un round da sei milioni di dollari<\/a> guidato da Variant e 1kx, era stata tra le prime a misurare in modo sistematico il costo dei sistemi di prova applicati all’AI, con il report \u00abThe Cost of Intelligence\u00bb. I suoi dimostratori vivevano dentro giochi on-chain con AI minuscole, come RockyBot, proprio perch\u00e9 tempo di prova e uso di memoria erano i vincoli decisivi. Finch\u00e9 il proving restava cos\u00ec lento, lo zk-ML era una curiosit\u00e0 da laboratorio.<\/p> Il muro ha iniziato a cedere quando la comunit\u00e0 ha cambiato approccio all’aritmetizzazione. Invece di codificare ogni funzione non lineare come un circuito, la si pu\u00f2 precalcolare in una tabella e poi dimostrare, tramite un argomento crittografico chiamato lookup, che un certo valore appartiene a quella tabella. Wyatt Benno, di ICME Labs, lo sintetizza senza mezzi termini: \u00abi lookup, al contrario, eliminano del tutto la necessit\u00e0 della rappresentazione a circuito\u00bb<\/a>.<\/p> Il filone tecnico pi\u00f9 discusso del 2026 \u00e8 Jolt Atlas, un adattamento della zkVM Jolt di a16z (basata su lookup e sul protocollo sumcheck) alle operazioni tensoriali dei modelli in formato ONNX, portato avanti da ICME Labs e NovaNet. L’idea di fondo \u00e8 che una macchina virtuale costruita quasi interamente su lookup elimina buona parte della complessit\u00e0 che rendeva costosa la non linearit\u00e0: niente polinomi quoziente, niente decomposizione in byte, niente prodotti a catena. I numeri iniziano a raccontare una storia diversa: sullo stesso modello di classificazione, un prover basato su Jolt impiega circa 0,7 secondi contro i 4-5 secondi di EZKL, la libreria che per anni \u00e8 stata il riferimento. Dalle ore dei primi sistemi a frazioni di secondo, il salto \u00e8 enorme.<\/p> Alla base di questi progressi c’\u00e8 proprio il sumcheck, un protocollo interattivo che consente di dimostrare in modo efficiente affermazioni su grandi somme di valori e che si sposa particolarmente bene con le operazioni tensoriali di una rete neurale. Combinato con i lookup, permette di trattare le funzioni non lineari senza costruire i circuiti mostruosi che le rappresentavano prima. \u00c8 un cambio di paradigma pi\u00f9 che un’ottimizzazione incrementale: sposta il collo di bottiglia dalla forma del modello alla pura quantit\u00e0 di calcolo, che \u00e8 esattamente il tipo di problema che l’hardware sa aggredire.<\/p> Il segnale pi\u00f9 forte che il 2026 sia un anno di svolta arriva da Lagrange e dal suo sistema DeepProve. A giugno l’azienda ha reso open source l’intero stack<\/a> (circuiti, prover, verificatore e pipeline ONNX), dichiarando oltre 12 milioni di prove generate e pi\u00f9 di 3 milioni di inferenze verificate dall’inizio alla fine nell’arco di un anno. Ma il dato che conta di pi\u00f9 \u00e8 un altro: DeepProve \u00e8 il primo sistema zk-ML di livello produttivo a dimostrare un’inferenza LLM completa<\/a>, con GPT-2 e Gemma-3 provati end-to-end e i modelli in stile Llama in fase di sviluppo attivo. Rispetto allo stato dell’arte precedente, l’azienda rivendica prove fino a 60 volte pi\u00f9 veloci e verifiche 671 volte pi\u00f9 rapide, senza perdita di accuratezza; il sistema legge modelli in ONNX, safetensors e GGUF, i formati con cui gli LLM vengono effettivamente distribuiti.<\/p> Il traguardo va letto con prudenza: dimostrare GPT-2, con le sue poche centinaia di milioni di parametri, non equivale a dimostrare un modello di frontiera da centinaia di miliardi, e i modelli in stile Llama sono ancora in corso. Ma la direzione \u00e8 chiara, e il fondatore e CEO di Lagrange, Ismael Hishon-Rezaizadeh, l’ha inquadrata cos\u00ec: \u00abNon abbiamo costruito DeepProve per possedere l’AI verificabile. L’abbiamo costruito perch\u00e9 nessuno dovesse farlo\u00bb. La sua sintesi del momento \u00e8 netta: \u00aboggi DeepProve diventa una primitiva, la scatola nera \u00e8 aperta\u00bb. Come dimostrazione pubblica, Lagrange ha usato Turing Roulette, un esperimento con oltre 500.000 partecipanti e 3,7 milioni di inferenze verificate<\/a> dal vivo.<\/p> Lo zk-ML non \u00e8 un prodotto unico ma un ecosistema di librerie e sistemi di prova, ciascuno con un compromesso diverso tra facilit\u00e0 d’uso, velocit\u00e0 e generalit\u00e0. La tabella riassume i protagonisti principali.<\/p>Le tre propriet\u00e0 di una prova a conoscenza zero<\/h2>
Dal modello alla prova: il ciclo di vita<\/h2>
Primo ostacolo: le operazioni non lineari<\/h2>
Secondo ostacolo: la virgola mobile<\/h2>
Terzo ostacolo: la scala<\/h2>
La svolta dei lookup e il 2026<\/h2>
DeepProve e la prima prova di un LLM intero<\/h2>
La mappa degli strumenti nel 2026<\/h2>