ZK specializzato vs. ZK generale: qual è il futuro?
Specializzazione e generalizzazione, qual è il futuro di ZK? Provo a rispondere a questa domanda con un diagramma:
Come mostrato nel diagramma, è possibile convergere in futuro verso un punto magico ottimale sul sistema di coordinate del trade-off?
No, il futuro del calcolo verificabile fuori catena è una curva continua che sfuma i confini tra ZK specializzato e ZK generale. Permettetemi di spiegare l’evoluzione storica di questi termini e come convergeranno in futuro.
Due anni fa, per infrastruttura ZK “specializzata” si intendevano framework di circuiti di basso livello come circom, Halo2 e arkworks. Le applicazioni ZK costruite con questi framework erano essenzialmente circuiti ZK scritti a mano. Erano veloci e convenienti per compiti specifici, ma in genere difficili da sviluppare e mantenere. Sono simili ai vari chip di circuiti integrati specializzati (wafer fisici di silicio) dell’industria IC di oggi, come i chip NAND e i chip controller.
Tuttavia, negli ultimi due anni, l’infrastruttura ZK specializzata è diventata gradualmente più “generalizzata”.
Ora abbiamo i framework ZKML, ZK coprocessor e ZKSQL che offrono SDK facili da usare e altamente programmabili per costruire diverse categorie di applicazioni ZK senza scrivere una sola riga di codice del circuito ZK. Ad esempio, il coprocessore ZK consente agli smart contract di accedere in modo affidabile agli stati storici, agli eventi e alle transazioni della blockchain e di eseguire calcoli arbitrari su questi dati. ZKML consente ai contratti intelligenti di utilizzare i risultati dell’inferenza dell’intelligenza artificiale in modo affidabile per gestire un’ampia gamma di modelli di apprendimento automatico.
Questi framework evoluti migliorano significativamente la programmabilità nei loro domini di destinazione, mantenendo alte prestazioni e bassi costi grazie a sottili livelli di astrazione (SDK/API) che si avvicinano ai circuiti bare-metal.
Sono simili a GPU, TPU e FPGA nel mercato dei circuiti integrati: specialisti del dominio programmabile.
Anche ZKVM ha fatto passi da gigante negli ultimi due anni. In particolare, tutte le ZKVM generiche sono costruite sulla base di framework ZK specializzati di basso livello. L’idea è che si possano scrivere applicazioni ZK in linguaggi di alto livello (ancora più facili da usare rispetto a SDK/API), che si compilano in una combinazione di circuiti e set di istruzioni specializzati (RISC-V o simili a WASM). Sono come i chip delle CPU nell’industria dei circuiti integrati.
ZKVM è un livello di astrazione sopra i framework ZK di basso livello, proprio come i coprocessori ZK.
Come disse una volta una persona saggia, un livello di astrazione può risolvere tutti i problemi informatici, ma contemporaneamente ne crea un altro. La chiave è il compromesso. Fondamentalmente, per ZKVM, scambiamo prestazioni e generalità.
Due anni fa, le prestazioni di ZKVM “bare-metal” erano davvero scarse. Tuttavia, in soli due anni, le prestazioni di ZKVM sono migliorate in modo significativo.
Perché?
Perché queste ZKVM “generiche” sono diventate più “specializzate”. Uno dei motivi principali del miglioramento delle prestazioni è la “precompilazione”. Queste precompilazioni sono circuiti ZK specializzati in grado di calcolare programmi comuni di alto livello, come SHA2 e varie verifiche di firma, molto più velocemente rispetto alla scomposizione in frammenti di circuiti di istruzioni.
Pertanto, la tendenza è ormai chiara.
L’infrastruttura ZK specializzata sta diventando sempre più generalizzata, mentre le ZKVM generali stanno diventando sempre più specializzate.
L’ottimizzazione di entrambe le soluzioni negli ultimi anni ha permesso di raggiungere un punto di compromesso migliore rispetto al passato: fare progressi su un punto senza sacrificarne un altro. Ecco perché entrambe le parti ritengono che “siamo decisamente il futuro”.
Tuttavia, la saggezza informatica ci dice che a un certo punto incontreremo il “muro dell’optimum di Pareto” (linea verde tratteggiata), dove non possiamo migliorare una prestazione senza sacrificarne un’altra.
Sorge quindi una domanda da un milione di dollari:
Una tecnologia sostituirà completamente un’altra al momento giusto?
Prendendo spunto dal settore dei circuiti integrati: il mercato delle CPU è di 126 miliardi di dollari, mentre l’intero settore dei circuiti integrati (compresi tutti i circuiti integrati “specializzati”) è di 515 miliardi di dollari. Sono convinto che, da un punto di vista micro, la storia si ripeterà in questo caso e i due prodotti non si sostituiranno a vicenda.
Detto questo, oggi nessuno direbbe: “Ehi, sto usando un computer interamente gestito da una CPU generica” o “Ehi, questo è un robot di lusso gestito da circuiti integrati specializzati”.
Sì, dobbiamo considerare la questione da una prospettiva macro e in futuro ci sarà una curva di compromesso che consentirà agli sviluppatori di scegliere in modo flessibile in base alle loro esigenze.
In futuro, l’infrastruttura ZK specializzata e la ZKVM generale potranno lavorare insieme. Questo può essere realizzato in diverse forme. Il metodo più semplice è già realizzabile ora. Ad esempio, è possibile utilizzare un coprocessore ZK per generare alcuni risultati di calcolo nella cronologia delle transazioni della blockchain, ma la logica aziendale di calcolo su questi dati è molto complessa e non può essere semplicemente espressa nell’SDK/API.
È possibile ottenere prove ZK ad alte prestazioni e a basso costo dei dati e dei risultati di calcolo intermedi, quindi aggregarli in una macchina virtuale generica attraverso prove ricorsive.
Sebbene trovi interessante questo tipo di dibattito, so che stiamo tutti costruendo questo futuro informatico asincrono guidato dalla computazione verificabile fuori catena per blockchain. Nei prossimi anni, con l’emergere dei casi d’uso per l’adozione di massa da parte degli utenti, credo che questo dibattito giungerà finalmente a una conclusione.