Verifiable compute: cos’è e come funziona nell’AI crypto

«Decentralizzato» non è lo stesso di «verificato»

Il 4 maggio 2026 un utente su X ha convinto l’agente AI Grok, integrato con il bot di trading Bankr, a trasferire circa 3 miliardi di token DRB, tra i 130.000 e i 175.000 euro al cambio dell’epoca, fuori da un wallet che l’agente controllava. Il trucco non aveva nulla di sofisticato dal punto di vista crittografico: un NFT «Bankr Club Membership» inviato in regalo ha sbloccato permessi «Executive» nel wallet dell’agente, bypassando i normali limiti di trasferimento, e un messaggio in codice Morse pubblicato come risposta su X ha convinto il modello a tradurlo ed eseguirlo come un’istruzione legittima, cioè inviare fondi a un indirizzo scelto dall’attaccante. Nessun bug nello smart contract, nessuna chiave privata rubata: solo un modello linguistico che ha eseguito un calcolo, quello che l’attaccante gli ha chiesto di fare, senza che nessuno potesse verificare in anticipo se il risultato fosse legittimo.

L’episodio, catalogato nel database ufficiale degli incidenti AI dell’OCSE, riassume bene il problema che il verifiable compute prova a risolvere. Man mano che agenti AI autonomi firmano transazioni, oracoli alimentano protocolli DeFi con dati elaborati da modelli di machine learning e i mercati predittivi si affidano a un’AI per interpretare un evento del mondo reale, la domanda cambia: non più «questo sistema è decentralizzato?», ma «posso verificare che questo calcolo sia stato eseguito correttamente, senza dover rifare il lavoro io stesso?». Sono due domande diverse, e la crypto degli ultimi due anni ha iniziato a trattarle come tali, con un intero filone di progetti, da EigenCloud a Boundless, da Succinct a Phala Network, nato apposta per rispondere alla seconda.

Cos’è il verifiable compute: la definizione

Il termine verifiable compute indica un calcolo che produce, insieme al risultato, una prova a basso costo che quel risultato è stato ottenuto correttamente, cosicché chi la riceve non debba ripetere l’intero calcolo per fidarsi. Il costo di verifica deve restare molto più basso del costo di esecuzione originale: altrimenti tanto varrebbe rieseguire tutto da capo, vanificando lo scopo stesso della prova.

Vitalik Buterin ha inquadrato il tema in un saggio del gennaio 2024 che resta ancora oggi il riferimento concettuale del settore, proponendo una tassonomia in quattro categorie per le applicazioni che combinano crypto e AI e osservando che il nodo cruciale, in ognuna di esse, è sempre lo stesso: come si fa a sapere che un output prodotto da un modello, spesso opaco e costoso da rieseguire, riflette davvero l’esecuzione onesta di quel modello, e non un dato inventato, un modello sostituito con uno più economico o un input manipolato.

È importante distinguere il verifiable compute dal semplice calcolo decentralizzato. Reti come Akash Network o Bittensor permettono di affittare potenza di calcolo, GPU comprese, da un mercato distribuito di provider invece che da AWS o Google Cloud: questo abbassa i costi e riduce la dipendenza da un singolo fornitore, ma non prova che il provider abbia eseguito il lavoro richiesto in modo onesto. Il verifiable compute affronta un problema diverso e più stretto: non «dove gira il calcolo», ma «come faccio a fidarmi del risultato». Torneremo su questa distinzione più avanti, perché è anche il modo più semplice per capire cosa il settore intende davvero quando parla di AI «verificabile».

Il problema di fiducia: agenti AI e il caso Grok/Bankr

Il caso Grok/Bankr non è isolato. Nello stesso periodo, diversi ricercatori di sicurezza hanno documentato una serie di attacchi di prompt injection indiretta, in cui istruzioni malevole vengono nascoste in pagine web, metadati o contenuti che un agente AI legge nel corso del proprio lavoro: l’agente, che non distingue in modo affidabile tra un’istruzione del proprio proprietario e un testo qualunque che sta processando, finisce per eseguire il comando nascosto come se fosse legittimo. Il problema di fondo, per come lo hanno descritto più volte i ricercatori del settore, è strutturale: un modello linguistico non separa in modo affidabile «istruzione» da «dato», e finché resta così, ogni agente con accesso a un wallet resta un bersaglio.

Il settore degli agenti AI on-chain ha già vissuto una traiettoria simile su un altro fronte, quello della fiducia negli operatori piuttosto che nel codice sottostante: il fondo ai16z, poi rinominato ElizaOS, è passato da una capitalizzazione miliardaria a poche centinaia di migliaia di dollari nel giro di mesi, con una causa legale degli investitori tuttora in corso. La lezione, applicata al calcolo invece che alla governance del token, è la stessa: un framework tecnicamente valido non basta a garantire che l’esecuzione sottostante sia quella dichiarata, se non esiste un modo indipendente per controllarla.

Il verifiable compute prova a spostare il baricentro della fiducia: invece di fidarsi dell’operatore, del provider cloud o del framework, si verifica la prova matematica, crittografica o economica allegata al risultato. Le quattro strade percorse finora dal settore per arrivarci sono lo zkML, i Trusted Execution Environment (TEE), l’opML e l’approccio crypto-economico basato su stake e slashing.

Quattro strade per verificare un calcolo

Ognuno dei quattro approcci sposta la fiducia su un fondamento diverso: la matematica, l’hardware, gli incentivi economici o un meccanismo di contestazione con una finestra temporale. Nessuno dei quattro è oggi universalmente superiore agli altri; ognuno scambia qualcosa, velocità, costo o grado di decentralizzazione, per qualcos’altro.

• zkML: prova crittografica generata insieme al risultato, verificabile con la sola matematica.
• TEE: attestazione hardware prodotta da un’enclave sicura del processore.
• opML: pubblicazione ottimistica del risultato, con una finestra di tempo per contestarlo.
• Crypto-economico: stake e slashing, dove barare costa più di quanto renda.

zkML: la prova crittografica del calcolo

Lo zkML applica le prove a conoscenza zero, la stessa tecnologia che alimenta i rollup Ethereum, alla verifica dell’inferenza o dell’addestramento di un modello AI. Il principio è identico a quello usato per comprimere l’esecuzione di uno smart contract in una prova succinta: il prover esegue il calcolo e produce una prova che chiunque può verificare in una frazione del tempo necessario per rieseguire l’originale, senza dover rivelare né i pesi del modello né i dati di input, se richiesto.

Il problema è che la generazione della prova ha un costo computazionale che cresce più che linearmente rispetto alla dimensione del modello, il che rende lo zkML puro impraticabile oggi su modelli linguistici da miliardi di parametri: funziona bene su modelli piccoli o su singoli passaggi di una pipeline più ampia, molto meno su un intero modello di scala GPT.

Il progetto che più ha spinto sul fronte degli zkVM, macchine virtuali a conoscenza zero capaci di generare prove per programmi scritti in linguaggi comuni come Rust invece che per circuiti su misura, è Succinct, con il suo SP1, uno zkVM basato su architettura RISC-V lanciato in mainnet il 5 agosto 2025. La rete conta oggi oltre 35 protocolli che si appoggiano a SP1, tra cui Polygon e Celestia, e rivendica oltre 5 milioni di prove generate a protezione di più di 3,5 miliardi di euro di valore (circa 4 miliardi di dollari). Il token PROVE, che remunera e penalizza tramite slashing i prover della rete, vale una manciata di centesimi di euro a metà luglio 2026, con solo lo 0,68% della supply oggi in staking, un segnale di partecipazione ancora limitata da parte dei prover; gli sblocchi di token per team e investitori, che partono nel primo trimestre 2026, aggiungeranno pressione sull’offerta nei prossimi mesi (dati e capitalizzazioni precisi nella tabella più avanti).

Accanto a Succinct opera Boundless, incubato da RISC Zero e pensato come mercato delle prove agnostico rispetto al protocollo: un tenant può chiedere una prova generata con SP1, con lo stack di RISC Zero o con altri sistemi, e Boundless si occupa di trovare un prover disponibile. Il mainnet, lanciato su Base a settembre 2025, ha elaborato secondo i dati riportati da RockawayX circa 542.700 miliardi di cicli di calcolo distribuiti su quasi 400.000 ordini nei primi mesi di attività. Il meccanismo di incentivo si chiama Proof of Verifiable Work: i prover vengono ricompensati in base a quanto calcolo elaborano, quanto velocemente e con quale grado di complessità. «Per la prima volta, gli sviluppatori su qualsiasi chain possono accedere a calcolo a conoscenza zero in abbondanza per costruire applicazioni complesse che scalano tra ecosistemi diversi senza sacrificare la decentralizzazione», ha dichiarato Shiv Shankar, CEO di Boundless, al lancio del mainnet, secondo quanto riportato da CoinDesk. Tra i primi partner del protocollo figurano Wormhole, che lo usa per aggiungere verifica ZK al consenso Ethereum, e Lido, per la sicurezza delle uscite dei validatori.

Sul fronte della sicurezza di lungo periodo, le prove a conoscenza zero attuali si basano spesso su assunzioni crittografiche che, come nel caso delle firme Schnorr di Taproot su Bitcoin, un giorno potrebbero dover affrontare la minaccia dei computer quantistici; alcuni schemi più recenti, basati su funzioni hash piuttosto che su curve ellittiche, sono già progettati pensando a questa eventualità, ma resta un fronte che il settore osserva con un orizzonte pluriennale, non come un’urgenza immediata.

TEE: fidarsi (in parte) dell’hardware

I Trusted Execution Environment spostano il problema dall’algoritmo all’hardware. Un TEE è un’enclave isolata all’interno del processore, protetta anche dal sistema operativo che la ospita, capace di generare un’attestazione firmata crittograficamente che certifica quale codice sta girando e che l’ambiente non è stato manomesso. Chi riceve l’attestazione non deve fidarsi dell’operatore del server, ma deve comunque fidarsi del produttore del chip: se Intel, AMD o NVIDIA hanno un bug nel design dell’enclave, o se un ricercatore scopre un attacco side-channel, cioè una fuga di informazioni attraverso canali indiretti come il consumo energetico o i tempi di risposta e non attraverso una violazione diretta, la garanzia crolla. Intel TDX e AMD SEV coprono la CPU; per l’AI conta soprattutto la GPU, dove NVIDIA ha esteso il proprio Confidential Computing agli H100 con un overhead dichiarato inferiore al 7% rispetto all’esecuzione non protetta, un costo abbastanza contenuto da rendere il TEE l’approccio più praticabile oggi per l’inferenza su modelli di grandi dimensioni.

Phala Network è il progetto crypto che ha costruito la rete di TEE più estesa, con oltre 30.000 dispositivi che combinano Intel TDX per la CPU e TEE dedicati per le GPU NVIDIA, attestazione on-chain dei risultati e, secondo i dati diffusi dallo stesso progetto, oltre un miliardo di token di inferenza elaborati al giorno tramite l’integrazione con OpenRouter fin da marzo 2026, con punte fino a 3,28 miliardi di token in una singola giornata.

Anche EigenCloud, il rebranding di EigenLayer verso quella che il fondatore Sreeram Kannan chiama la «verifiable cloud» della crypto, appoggia una parte della propria offerta ai TEE: EigenCompute, in mainnet alpha da fine settembre 2025, permette di caricare la logica di un’applicazione o di un agente come immagine Docker ed eseguirla dentro un ambiente attestato, con un’integrazione che fa girare EigenCompute anche su Google Cloud Confidential Space con attestazione Intel TDX, un dettaglio pensato esplicitamente per rassicurare i clienti enterprise abituati a fidarsi dell’infrastruttura cloud tradizionale piuttosto che di un protocollo crypto-nativo. La sorella di EigenCompute, EigenAI, offre invece un’API compatibile con quella di OpenAI per l’inferenza verificabile, e rivendica di aver ottenuto, tramite un’analisi approfondita dello stack di calcolo, un’esecuzione bit-exact e deterministica dell’inferenza di modelli linguistici su GPU, a partire dal modello open gpt-oss-120b: un risultato tecnicamente non banale, perché normalmente l’inferenza su GPU non è deterministica a causa dell’aritmetica in virgola mobile e della parallelizzazione, per cui due esecuzioni identiche possono restituire output leggermente diversi. Come ha spiegato Kannan al podcast Bankless: «Qualunque cosa tu possa programmare sul cloud, dovresti poterla programmare su Eigencloud con una verificabilità di livello crypto. Se lo fai su questo, non hai bisogno di fidarti di nessuno».

opML: ottimismo e finestre di contestazione

L’apprendimento automatico ottimistico, o opML, importa nel machine learning la stessa logica dei rollup ottimistici usati per scalare Ethereum: chi esegue il calcolo pubblica il risultato senza allegare alcuna prova immediata, ma apre una finestra di tempo durante la quale chiunque può contestarlo presentando una fraud proof, cioè una prova di frode che dimostra dove esattamente il calcolo dichiarato diverge da quello corretto. Se nessuno lo contesta entro la finestra, il risultato si considera finale.

Ora, il progetto che ha proposto per primo questo schema in un paper del gennaio 2024, lo presenta come il modo più economico per verificare modelli di grandi dimensioni: in assenza di dispute, il costo aggiuntivo rispetto a un’esecuzione non verificata è minimo. Il prezzo da pagare sono due vincoli piuttosto stringenti: serve una finestra di contestazione, che introduce latenza e rende l’opML poco adatto a un’interazione in tempo reale, e serve almeno un osservatore onesto e attento, disposto a controllare i risultati e a sollevare una contestazione quando serve, altrimenti l’intero schema di sicurezza si regge sul nulla.

L’approccio crypto-economico: stake, slashing e EigenCloud

L’approccio crypto-economico non prova nulla in senso crittografico né si affida all’hardware: rende semplicemente più conveniente essere onesti che barare. Un operatore deposita una garanzia in stake; se un meccanismo di verifica, spesso più leggero e probabilistico della verifica completa, rileva un comportamento scorretto, quella garanzia viene bruciata in parte o del tutto tramite slashing. Il meccanismo funziona quando il costo di essere scoperti supera in modo affidabile il guadagno ottenibile barando: è quindi una garanzia economica, non matematica, e un attaccante con capitale sufficiente, o disposto a perdere lo stake per un guadagno una tantum più grande, può ancora trovare conveniente comportarsi in modo scorretto.

EigenCloud costruisce questa logica sopra il meccanismo di restaking di Ethereum: gli operatori che già mettono in stake ETH per proteggere la rete possono ri-mettere in stake lo stesso capitale per garantire servizi aggiuntivi, i cosiddetti Actively Validated Service, e sia EigenCompute sia EigenAI sono, in questo schema, due AVS pensati specificamente per l’AI verificabile.

Un altro progetto che lavora sul lato crypto-economico, con un’architettura diversa, è Gensyn: invece di rieseguire l’intero calcolo o produrre una prova crittografica, il suo sistema di verifica, chiamato Verde, individua il primo passaggio in cui l’esecuzione contestata diverge da quella corretta e rielabora solo quel passaggio, non l’intero grafo computazionale, per arbitrare la disputa; il tutto si appoggia su operatori matematici «riproducibili» (RepOps) che garantiscono lo stesso risultato bit per bit anche su hardware diverso, un problema che la sola aritmetica in virgola mobile standard non risolve da sola. È un ibrido tra l’approccio crypto-economico e l’opML più che un quarto approccio puro, un buon esempio di come i confini tra le categorie, nella pratica, sfumino l’uno nell’altro.

Il 2026 degli ibridi: quando una tecnica sola non basta

Nessuno dei quattro approcci, preso da solo, risolve il problema in modo soddisfacente su scala: lo zkML è troppo lento sui modelli grandi, i TEE spostano ma non eliminano la fiducia, l’opML introduce latenza, il crypto-economico offre solo una garanzia probabilistica. La direzione che il settore ha preso nel 2026 è combinare più approcci nello stesso sistema, piuttosto che sceglierne uno solo.

Un filone di ricerca recente, che circola sotto l’etichetta di «Optimistic TEE-Rollup», propone esattamente questo: un TEE come gli H100 di NVIDIA per ottenere finalità rapida sulla maggior parte delle richieste, un meccanismo ottimistico con fraud proof come rete di sicurezza se l’attestazione hardware viene compromessa, e controlli a campione con prove a conoscenza zero, applicati in modo stocastico solo a una frazione delle richieste, per tenere sotto controllo i costi mantenendo comunque una garanzia crittografica residua. Chi lavora su questi sistemi ibridi descrive il compromesso di fondo come un «trilemma della verificabilità»: integrità, latenza e costo, di cui si possono ottimizzare al massimo due contemporaneamente.

C’è poi un problema più sottile, quasi filosofico, che complica ogni tentativo di combinare zkML e verifica dell’inferenza AI su GPU: le prove a conoscenza zero richiedono che il calcolo sia deterministico, cioè che dati identici in ingresso producano sempre lo stesso output, mentre l’inferenza di un modello linguistico su GPU, per via dell’aritmetica in virgola mobile e dell’ordine di esecuzione delle operazioni in parallelo, normalmente non lo è. È il motivo per cui il lavoro di EigenAI sul determinismo bit-exact, o quello di Gensyn sui RepOps, non è un dettaglio tecnico marginale ma una precondizione perché zkML e opML possano applicarsi all’AI generativa su larga scala in modo affidabile.

Non tutto il calcolo decentralizzato è verificabile: il caso Akash

La distinzione tra «decentralizzato» e «verificabile» emerge con chiarezza se si guarda ad Akash Network, il mercato del calcolo decentralizzato più affermato del settore crypto. Akash permette a chiunque abbia GPU disponibili di affittarle tramite un’asta al ribasso, con un tenant che pubblica le proprie esigenze e i provider che competono sul prezzo: un modello che ha attirato clienti reali, tra cui gli stessi Venice, ElizaOS e Gensyn per parte della loro inferenza, ma che non include alcun meccanismo per dimostrare che il provider abbia effettivamente eseguito il carico di lavoro dichiarato, con il modello dichiarato, sull’hardware dichiarato.

Il fondatore Greg Osuri ha inquadrato la sfida di Akash in termini di scala dell’offerta piuttosto che di verifica, quando ha scritto nel report del primo trimestre 2026 della rete che «l’AI si muove in mesi, l’energia si muove in anni», riferendosi alla difficoltà di far crescere la capacità GPU disponibile alla velocità con cui cresce la domanda. È una sfida reale, ma diversa da quella che il verifiable compute prova a risolvere: i dati di Akash relativi al primo trimestre 2026 mostrano un tasso di utilizzo della capacità GPU disponibile intorno al 33,7%, un numero che riguarda quanto della capacità offerta viene effettivamente affittata, non se il lavoro affittato viene eseguito onestamente.

Questo non rende Akash un progetto peggiore, semplicemente diverso: è un mercato di risorse, non un sistema di prova. Lo stesso vale, con un meccanismo differente, per Bittensor, la cui rete premia i partecipanti («miner») che producono output di machine learning giudicati migliori da altri partecipanti («validator»): un sistema di reputazione e competizione tra pari, che può incentivare risultati di qualità nel tempo, ma che resta concettualmente distinto da una prova verificabile del singolo calcolo. Il token TAO di Bittensor, con una capitalizzazione intorno a 1,61 miliardi di euro a metà luglio 2026 pur essendo in calo di oltre il 30% nell’ultimo mese, resta comunque il più capitalizzato tra i token citati in questo articolo, a conferma che il mercato premia per ora soprattutto l’adozione, più che la garanzia crittografica in senso stretto.

Applicazioni pratiche: agenti, oracoli e conformità

Al di là della teoria, il verifiable compute risolve problemi concreti in almeno tre aree.

Il primo è la firma autonoma di transazioni da parte di agenti AI: un agente che deve decidere se scambiare un asset, fornire liquidità o eseguire un pagamento tramite protocolli come x402 di Coinbase può, in teoria, allegare alla propria decisione una prova verificabile che quella decisione discende effettivamente dal modello dichiarato e dai dati che ha ricevuto, riducendo, senza eliminarlo del tutto, lo spazio per un attacco come quello subito da Grok.

Il secondo sono gli oracoli, cioè i sistemi che portano dati dal mondo reale, prezzi, eventi, risultati, dentro uno smart contract: un oracolo che usa un modello AI per interpretare un evento ambiguo, per esempio il risultato di un evento sportivo o l’esito di un procedimento per un mercato predittivo, può allegare una prova che l’interpretazione discende da un’esecuzione verificabile del modello, invece che dalla parola di un singolo operatore centralizzato.

Il terzo, ancora agli inizi ma quello con il potenziale commerciale più immediato secondo diversi osservatori del settore, è l’adozione da parte di clienti enterprise regolamentati, per cui la verificabilità non è solo una garanzia crypto-nativa ma un requisito di conformità: poter dimostrare, con un’attestazione crittografica, quale modello ha preso una decisione automatizzata e con quali dati è esattamente il tipo di tracciabilità che le autorità finanziarie chiedono sempre più spesso, anche fuori dal mondo crypto puro, man mano che le banche stesse iniziano ad avvicinarsi a questa infrastruttura, come raccontato nell’approfondimento di HOGE Wire su come cambiano le regole per le banche che vogliono offrire servizi legati alle cripto-attività.

Prezzi e capitalizzazione: la mappa del settore

I token che remunerano chi fornisce potenza di calcolo verificabile restano, nel complesso, piccoli rispetto ai giganti del settore crypto, e parecchio volatili. La tabella seguente confronta i principali token citati in questo articolo, con dati CoinGecko aggiornati al 17 luglio 2026 e convertiti in euro; trattandosi di un mercato illiquido, i prezzi possono muoversi in modo sensibile anche nel giro di poche ore, e vanno quindi trattati come una fotografia del momento, non come un valore stabile.

Il confronto è istruttivo: Akash, che non offre alcuna garanzia crittografica o economica sull’onestà del calcolo, ha oggi una capitalizzazione superiore a tre dei quattro progetti di verifiable compute elencati in tabella, segno che il mercato non ha ancora imparato a distinguere con chiarezza, nel prezzo, tra calcolo distribuito e calcolo verificato. Va anche detto che si tratta di categorie di mercato ancora giovani: EigenCloud, il progetto più capitalizzato tra quelli nativi del verifiable compute, vale oggi una frazione minima della capitalizzazione che aveva al proprio picco di fine 2024, quando operava ancora sotto il nome EigenLayer e il mercato del restaking viveva la sua fase più speculativa.

Il quadro normativo italiano: Consob, Banca d’Italia e fisco

In Italia, come nel resto dell’Unione, l’infrastruttura di verifiable compute in sé, cioè il software che genera prove crittografiche o gestisce enclave TEE, non è oggetto di una disciplina specifica: non è un servizio finanziario, non custodisce fondi di terzi, non emette strumenti di pagamento. Il perimetro normativo si attiva un gradino più in alto, quando quell’infrastruttura viene usata per remunerare un token, per offrire un servizio a clienti retail o per supportare un agente AI che gestisce asset per conto di terzi.

Dal 1° luglio 2026 è terminato anche in Italia il periodo transitorio del regolamento MiCA, con scadenza per la presentazione delle domande di autorizzazione fissata al 30 giugno, e da quella data solo i prestatori di servizi per le cripto-attività (CASP) autorizzati possono operare sul mercato italiano; il decreto legislativo 5 settembre 2024, n. 129 ha adattato il quadro MiCA all’ordinamento italiano, affidando a Consob la vigilanza su trasparenza e correttezza dei comportamenti verso gli investitori e a Banca d’Italia la vigilanza prudenziale, compresa quella sui token collegati a valuta. Consob ha inoltre recepito gli orientamenti ESMA che spiegano come distinguere una cripto-attività disciplinata da MiCA da uno strumento finanziario disciplinato dal MiFID II, una distinzione tutt’altro che teorica per un token come EIGEN o PROVE, il cui valore dipende in parte da flussi di commissioni generati dalla rete: se la sostanza economica di un token si avvicina troppo a quella di uno strumento finanziario, per esempio una promessa di rendimento legata al lavoro di un team identificabile, la qualificazione può spostarsi dal regime MiCA a quello, più stringente, del MiFID II, indipendentemente da come il progetto etichetta se stesso.

Un secondo fronte, meno discusso ma concreto, riguarda l’AI in sé: l’ESMA ha chiarito che l’uso di sistemi di intelligenza artificiale nei servizi di investimento non sospende gli obblighi di governance, trasparenza e supervisione umana previsti dal MiFID II, un principio che si applica per estensione anche a un ipotetico agente AI verificabile che eseguisse operazioni finanziarie per conto di un cliente italiano: la prova crittografica che il modello ha girato come dichiarato non sostituisce l’obbligo di sorveglianza umana sul risultato.

Sul fronte fiscale, chi partecipa a queste reti mettendo in stake EIGEN, PHA, PROVE o AKT per fare da operatore, prover o nodo di verifica e riceve ricompense in token tratta quei proventi secondo le stesse regole ordinarie applicate a staking e restaking, un tema su cui HOGE Wire ha già pubblicato una guida pratica su cosa cambia nella tassazione delle cripto-attività oltre alla sola aliquota del 33%. Chi invece ha guadagni pregressi su questi token e ha mancato la scadenza di dichiarazione di fine giugno può ancora rimediare, come spiegato nella guida di HOGE Wire su cosa fare se si è saltata la scadenza del 30 giugno.

Rischi, limiti e cosa aspettarsi nel resto del 2026

Vitalik Buterin, nello stesso saggio citato in apertura, ha sintetizzato un vincolo che resta valido oggi come nel 2024: più un’applicazione crypto e AI è economicamente rilevante, più cresce l’incentivo a barare, e più deve essere robusto il meccanismo di verifica; ma i meccanismi di verifica più robusti, lo zkML puro in cima alla lista, sono anche i più costosi da eseguire. Il settore, in altre parole, non ha ancora un modo economico di verificare in modo crittograficamente perfetto un modello da centinaia di miliardi di parametri, e potrebbe non averlo per diversi anni.

I limiti restano quelli descritti approccio per approccio: lo zkML fatica sulla scala, i TEE spostano la fiducia sul produttore del chip invece di eliminarla, un problema non teorico, dato che nel corso degli anni sono stati pubblicati diversi attacchi side-channel contro enclave commerciali, l’opML introduce latenza incompatibile con un’interazione in tempo reale, e le garanzie crypto-economiche restano probabilistiche, valide solo finché il costo di essere scoperti supera il beneficio di barare.

Nel resto del 2026, gli indicatori più utili da seguire sono tre:

• se EigenAI ed EigenCompute passeranno dalla mainnet alpha alla disponibilità generale, ampliando la base di sviluppatori oltre ai primi partner come Coinbase AgentKit;
• se il rapporto tra prove generate e capitale in staking su reti come Succinct e Boundless comincerà a crescere più velocemente degli sblocchi di token in arrivo, segnale di una domanda reale che supera la fase speculativa;
• se emergerà un caso d’uso enterprise, fuori dal mondo crypto-nativo, disposto a pagare per la verificabilità come requisito di conformità piuttosto che come caratteristica accessoria.

Domande frequenti

Le risposte alle domande più cercate su questo tema.

Cos’è il verifiable compute?

Il verifiable compute è un modello di calcolo in cui, insieme al risultato di un’operazione, per esempio l’inferenza di un modello AI, viene prodotta anche una prova a basso costo che quel risultato è stato ottenuto correttamente. Chi riceve la prova può verificarla rapidamente, senza dover rieseguire l’intero calcolo per fidarsi del risultato: la fiducia si sposta dall’operatore del server alla prova stessa.

Che differenza c’è tra verifiable compute e calcolo decentralizzato come Akash o Bittensor?

Il calcolo decentralizzato, come quello offerto da Akash Network o dalle subnet di Bittensor, distribuisce l’esecuzione tra molti provider indipendenti invece che su un unico fornitore cloud, ma non include necessariamente un meccanismo per dimostrare che il provider abbia eseguito onestamente il lavoro richiesto. Il verifiable compute affronta esattamente questo problema aggiuntivo: non riguarda dove gira il calcolo, ma come si dimostra che il risultato è genuino.

Perché lo zkML fatica con i modelli AI di grandi dimensioni?

Le prove a conoscenza zero richiedono di trasformare l’intero calcolo in un circuito verificabile, un’operazione il cui costo cresce più che linearmente rispetto alla dimensione del modello. Su un modello linguistico da miliardi di parametri, generare una prova zero-knowledge completa dell’inferenza resta oggi troppo lento e costoso per un uso pratico su larga scala; funziona meglio su modelli piccoli o su singoli passaggi di una pipeline più ampia.

Come funziona la verifica tramite TEE (Trusted Execution Environment)?

Un TEE è un’area isolata del processore, protetta anche dal sistema operativo, che esegue il codice e produce un’attestazione firmata crittograficamente sul software in esecuzione e sull’integrità dell’ambiente. Chi riceve l’attestazione non deve fidarsi dell’operatore del server, ma deve comunque fidarsi del produttore del chip, Intel, AMD o NVIDIA, poiché un bug nel design dell’enclave o un attacco side-channel possono compromettere la garanzia.

Il verifiable compute è regolamentato in Italia sotto MiCA?

L’infrastruttura di verifiable compute in sé non rientra in una disciplina specifica, ma i token che remunerano chi la fornisce, se offerti o negoziati tramite un prestatore di servizi per le cripto-attività attivo in Italia, ricadono nel perimetro del regolamento MiCA, con vigilanza di Consob su trasparenza e correttezza e di Banca d’Italia sugli aspetti prudenziali, secondo quanto stabilito dal decreto legislativo 129 del 2024.

A cura della redazione di HOGE Wire.