Nuovi metodi di verifica puntano a sostituire la fiducia con la prova negli output di calcolo

Ogni volta che un computer produce un output, solleva una domanda fondamentale: la macchina ha davvero eseguito correttamente il programma previsto, sugli input dichiarati, per arrivare a quel risultato? Nella maggior parte dei contesti odierni, la risposta dipende dalla fiducia, stratificata con verifiche a posteriori. Ci fidiamo di un operatore cloud, di un fornitore di software, di una controparte o di un agente automatizzato, e poi facciamo leva su contratti, audit, log di accesso e processi di compliance per ridurre il rischio che qualcosa sia andato storto—o sia stato travisato.

Le zero-knowledge proofs (ZKP) propongono una base diversa. Invece di affidarsi principalmente a chi ha eseguito il calcolo, le ZKP rendono possibile affidarsi a ciò che il calcolo produce insieme al suo output: una prova crittografica compatta che il programma è stato eseguito come dichiarato. La prova funziona come un certificato che collega uno specifico programma e specifici input a un output specifico. Fondamentalmente, è progettata per essere minuscola e rapida da validare—spesso verificabile in millisecondi—così i destinatari possono confermare la correttezza senza dover rieseguire il lavoro in prima persona. E poiché la prova può essere “a conoscenza zero”, può fornire questa garanzia senza esporre input sensibili che devono rimanere privati.

Se la generazione di tali prove diventasse routinaria quanto eseguire software, cambierebbe il significato stesso di correttezza nei sistemi del mondo reale. Un agente di AI che agisce per conto di un utente potrebbe allegare una prova che ogni passaggio compiuto ha rispettato le policy ricevute. Istituzioni finanziarie che operano sotto una regolamentazione rigorosa potrebbero dimostrare che le transazioni sono state elaborate correttamente mantenendo riservati i dettagli sottostanti. In questo modello, la fiducia si sposta dalla reputazione istituzionale verso un’evidenza crittografica portabile, che può essere inoltrata e verificata in modo indipendente da chiunque abbia bisogno della stessa garanzia.

Il concetto non è nuovo. Le zero-knowledge proofs risalgono agli anni ’80, e l’idea più ampia di dimostrare la corretta esecuzione di un programma è studiata da decenni. Ciò che ha impedito alla tecnologia di diventare uno strumento di uso generale è che tre requisiti sono stati difficili da soddisfare simultaneamente: prestazioni, generalità con workflow a misura di sviluppatore, e garanzie crittografiche di lungo periodo.

Il primo è l’efficienza. Storicamente, produrre una prova poteva costare milioni di volte più calcolo rispetto alla semplice esecuzione del programma. Sebbene anni di ricerca abbiano ridotto sostanzialmente questo overhead, molti degli approcci più rapidi hanno raggiunto la loro velocità rinunciando ad altre proprietà desiderabili.

Il secondo è la generalità e l’usabilità. In molti sistemi ZKP, gli sviluppatori devono tradurre la logica applicativa in un “circuito” specializzato—una rappresentazione aritmetica del calcolo su misura per quello specifico programma. Quella traduzione può richiedere mesi, deve essere ripetuta ogni volta che il programma cambia, ed è essa stessa una fonte frequente di sottili falle di sicurezza. Un’alternativa più flessibile è dimostrare l’esecuzione di un processore standard, consentendo di provare direttamente il normale codice compilato. Ma fino a tempi recenti, quel tipo di proving general-purpose imponeva tipicamente forti penalizzazioni in termini di velocità o sicurezza.

Il terzo aspetto è la sicurezza—soprattutto in un mondo che si prepara al quantum computing. Molti sistemi di prova ampiamente utilizzati dipendono dalla crittografia a curve ellittiche (elliptic-curve cryptography), che potrebbe essere compromessa da un computer quantistico sufficientemente potente. Microsoft ha messo in evidenza questo rischio attraverso il suo Quantum Safe Program, nell’ambito del quale prevede di migrare prodotti e servizi verso la crittografia post-quantistica (post-quantum cryptography), una tempistica che l’azienda ha recentemente accelerato al 2029. Esistono sistemi di prova post-quantistici, ma molti si basano su assunzioni legate ai reticoli (lattice-based assumptions) e molti introducono anche nuove funzioni crittografiche pensate per ridurre i costi di generazione delle prove. Tali funzioni non hanno beneficiato dei decenni di analisi che sostengono gran parte della sicurezza dell’internet odierno, e alcune dipendono da congetture non dimostrate legate ai codici di correzione degli errori (error-correcting codes)—il che significa che i guadagni prestazionali possono arrivare insieme ad assunzioni più forti e meno collaudate dal tempo.

Su questo sfondo, Microsoft Research ha trascorso più di un decennio lavorando per rendere pratico il verifiable computing. I primi sforzi hanno perseguito due strade percorribili solo per programmi relativamente piccoli. Una utilizzava metodi interattivi—nei quali un verificatore controlla una lunga computazione tramite un breve scambio di botta e risposta con il prover—basandosi su tecniche come il protocollo sum-check, ma solo per computazioni con specifiche strutture a strati. Un’altra linea di lavoro faceva affidamento sulla crittografia a curve ellittiche per ottenere prove molto piccole, ereditando però la vulnerabilità quantistica di quelle fondamenta.

Perché è importante

Man mano che agenti software e calcolo in outsourcing assumono un ruolo maggiore nel processo decisionale, le organizzazioni hanno bisogno di modi per verificare gli esiti senza affidarsi ciecamente alla parte che svolge il lavoro. Il computing basato su prove potrebbe rendere più rapidi e più rispettosi della privacy la conformità normativa, l’audit e la collaborazione tra organizzazioni, trasformando la correttezza in qualcosa che può essere verificato crittograficamente. La prossima domanda cruciale è se i nuovi sistemi possano offrire velocità, programmabilità general-purpose e sicurezza post-quantistica senza fare affidamento su assunzioni troppo nuove—o troppo fragili—per basarvi infrastrutture critiche.