zkAPI affronta un problema concreto dell’intelligenza artificiale a consumo: pagare un servizio senza trasformare ogni richiesta in un pezzo della propria identità di fatturazione. Il progetto usa prove a conoscenza zero, ma non rende automaticamente anonimi i contenuti inviati a un modello.
La distinzione più importante, verificata il 26 ottobre 2026, riguarda anche lo stato del software: l’annuncio della Ethereum Foundation del 1° ottobre descrive un servizio su mainnet, mentre il ramo di sviluppo attuale contiene avvertenze su componenti e configurazioni non pronti per la produzione.
zkAPI: cosa vuole separare davvero
Nel post della Ethereum Foundation, il meccanismo separa l’autorizzazione della spesa dall’identità associata al deposito. Il provider continua a ricevere le richieste necessarie per svolgere il lavoro: privacy del pagamento e segretezza del prompt non sono la stessa proprietà.
Questo cambia la domanda da porre. Non basta chiedere se una chat è «privata»: bisogna capire quali soggetti vedono i contenuti, quali conoscono il pagamento e quali possono collegare le due informazioni attraverso altri dati.
Un’applicazione può ridurre un collegamento e lasciarne intatto un altro. Se una persona incolla nome, azienda e documento interno nella richiesta, un meccanismo di pagamento meno identificabile non elimina quelle informazioni dal testo ricevuto dal fornitore.
Il progetto di ricerca e il prodotto non coincidono
La proposta ZK API Usage Credits di Davide Crapis e Vitalik Buterin discute come combinare pagamento, riservatezza e protezione dagli abusi. È il contesto di ricerca: non è una descrizione automaticamente valida per ogni revisione del software successivo.
Per il lettore questo significa evitare un errore comune: prendere un diagramma teorico, una demo e un contratto attivo come se fossero tre prove intercambiabili della stessa cosa. Ogni elemento risponde a una domanda differente.
La ricerca spiega l’obiettivo; il codice mostra come una specifica versione cerca di raggiungerlo; un deployment verificato identifica ciò con cui l’utente può realmente interagire. La valutazione di sicurezza richiede che questi livelli siano collegati con precisione.
La verifica decisiva è sulla versione utilizzata
Il repository ufficiale, consultato il 26 ottobre, definisce sperimentale il protocollo e avverte che il ramo client dedicato alla privacy non è una release di produzione. Segnala inoltre configurazioni di deployment non ancora attive per la revisione corrente e una linea separata per note di una versione precedente.
Queste avvertenze non dimostrano che l’annuncio iniziale fosse falso o che ogni servizio precedente sia spento. Dimostrano però che scaricare il ramo principale non equivale a ottenere automaticamente la versione del servizio descritta all’inizio del mese.
Prima di usare denaro reale occorre quindi identificare release, rete, indirizzo del contratto e documentazione corrispondente. Se uno di questi riferimenti manca, fermarsi è una scelta corretta, non un problema da aggirare cambiando configurazioni a caso.
Che cosa protegge e che cosa resta da verificare
| Domanda | Lettura corretta | Controllo utile |
|---|---|---|
| Pagamento e richieste sono separati? | È l’obiettivo del protocollo | Esaminare la versione effettiva |
| Il modello legge il prompt? | La privacy del pagamento non lo impedisce | Limitare i dati inviati |
| Il ramo principale è pronto? | Non va presunto | Leggere gli avvisi di rilascio |
| Il deposito è senza rischio? | No | Valutare contratto, client e procedura di uscita |
Per ragionare sui metadati è utile anche il caso delle RPC dei wallet e della privacy. Un’informazione può essere protetta a un livello e continuare a essere osservabile da un altro servizio nella stessa catena.
Un esempio pratico, senza promesse di anonimato
Immaginiamo un assistente che deve classificare descrizioni di prodotti pubblici e consumare un budget limitato. Separare la provenienza del pagamento dalle singole operazioni potrebbe avere utilità, se il servizio e la release scelti supportano davvero quel percorso.
Se invece l’assistente elabora contratti riservati, il problema principale può essere il contenuto trasmesso. La scelta va confrontata con elaborazione locale, accordi sul trattamento dei dati e minimizzazione dei documenti: non soltanto con un diverso metodo di pagamento.
Questo è un esempio di valutazione, non un test di integrazione eseguito dalla redazione. Non abbiamo depositato fondi, verificato prelievi o misurato la resistenza del sistema alla correlazione delle sessioni.
Le domande da fare prima di una prova
La prima riguarda i confini: quale soggetto si vuole evitare che colleghi pagamento e utilizzo? La seconda riguarda i dati: quali informazioni entrano nella richiesta e quali finiscono nei log del client?
Seguono le verifiche operative: come si conserva lo stato locale, cosa accade se il dispositivo viene perso e quale procedura documentata consente di recuperare un saldo residuo? Una spiegazione generica della crittografia non sostituisce risposte concrete per la versione scelta.
Infine servono limiti di spesa e una gestione esplicita degli errori. Un’applicazione non dovrebbe passare silenziosamente a un percorso meno riservato solo perché il metodo preferito non risponde.
Perché seguirlo senza confonderlo con un investimento
zkAPI è interessante come tentativo di cambiare il rapporto tra accesso ai servizi e identità economica. Non serve trasformarlo in una tesi sul prezzo di Ethereum o in una promessa di rendimento per discuterne l’utilità.
Il criterio corretto rimane lo stesso della privacy crypto e dell’uso legittimo degli strumenti: definire il rischio, verificare i limiti e scegliere una soluzione proporzionata. Oggi la cautela più importante è non confondere una direzione promettente con una garanzia già dimostrata per ogni versione.
