A lungo, la tecnologia delle prove a conoscenza zero è stata considerata una tecnologia "teoricamente perfetta, ma lenta nella pratica" a causa dell'elevato costo computazionale e della lentezza del suo processo di generazione, rendendo difficile soddisfare i rigorosi requisiti di tempo di blocco della blockchain e ostacolando la sua applicazione in scenari reali. Tuttavia, nel 2025, questa situazione è stata completamente ribaltata, e le prestazioni di ZK non sono più il principale ostacolo alla sua applicazione. Una svolta significativa è rappresentata dal sistema di prove SP1 Hypercube sviluppato dal team Succinct. Ha dimostrato con successo la capacità di generare prove ZK per oltre il 93% dei blocchi della mainnet di Ethereum in un intervallo di tempo di 12 secondi, con un tempo medio di prova di soli 10,3 secondi. Per quanto riguarda il motivo per cui Succinct SP1 Hypercube è riuscito a ottenere un progresso tecnologico così significativo, si può comprendere semplicemente come derivante principalmente da due miglioramenti: 🔹 Il processo di generazione della prova ZK richiede di codificare i dati delle transazioni della blockchain in un polinomio matematico, e questo risultato di codifica aiuta a formare la prova finale. Si può immaginare come mettere un gran numero di bagagli disordinati in una valigia. I polinomi utilizzati in precedenza erano chiamati polinomi univariati, che non si adattavano bene alla struttura dei dati della blockchain, proprio come usare una valigia rotonda per oggetti quadrati, ci sono sempre spazi vuoti o compressioni, rendendo il lavoro di preparazione della codifica lungo e inefficiente. SP1 Hypercube ha inventato un nuovo polinomio (polinomi multilineari), che si adatta meglio alle caratteristiche multidimensionali dei dati delle transazioni, il che equivale a progettare una valigia rettangolare che può riempire perfettamente i bagagli. Questo ha notevolmente ridotto il tempo di preparazione della codifica dei dati, accelerando la generazione della prova da minuti a secondi, realizzando prove in tempo reale; 🔹 In precedenza, la generazione della prova era come un imballaggio manuale da parte di una sola persona, con l'intero processo che procedeva passo dopo passo, senza possibilità di suddivisione. Ora, SP1 Hypercube utilizza un nuovo algoritmo (inclusi aggregazione ricorsiva e protocolli ottimizzati) che consente di suddividere una grande prova in più compiti di prova più piccoli, ciascun compito gestito in modo indipendente e poi facilmente combinato in una prova completa. Il vantaggio della suddivisione è che consente di sfruttare appieno il calcolo parallelo su CPU o GPU multicore, proprio come più persone che imballano bagagli contemporaneamente, aumentando così notevolmente la velocità complessiva, in grado di tenere il passo con il ritmo di Ethereum di un blocco ogni 12 secondi, realizzando prove in tempo reale.

1/ 📖 Web3Caff Research 研报上线：《2025 以太坊生态与未来命运推演 2.5 万字研报：ZK 终局下，一场向内的深刻变革能否在历史洪流中继续突围领先？》 由 @Web3Caff_Res 研究员 @ChromiteMerge 撰写，系统解析以太坊在 2025 年的技术革新、生态重构与治理转向：从 L1 重振与 ZK 化，到 L2 转型与基金会战略演进，全景式呈现以太坊的关键拐点。 阅读全文👇

Nelle VM tradizionali, il consenso dipende da "tutti i nodi che eseguono ripetutamente ogni transazione", quindi la capacità di throughput dell'intera rete è limitata dal nodo più lento, e la potenza di calcolo viene sprecata in un gran numero di calcoli ripetuti. Nella zkVM, il processo è suddiviso in "esecuzione + prova + verifica": il programma e l'input devono essere eseguiti solo una volta nella zkVM, generando un risultato e una prova a conoscenza zero; gli altri nodi non devono ripetere i calcoli, ma devono solo verificare questa prova. In questo modo, il carico computazionale è notevolmente ridotto. Prendendo come esempio la zkVM di RISC Zero (d'ora in poi R0VM): 🔹 Essa utilizza il set di istruzioni RISC-V come nucleo, gli sviluppatori devono solo scrivere programmi guest in Rust / C / C++, e poi compilarli in file RISC-V ELF; 🔹 Ogni file ELF corrisponde a un ID immagine unico, utilizzato per garantire che "l'esecuzione sia effettivamente questo codice"; 🔹 Il risultato dell'esecuzione genera una ricevuta (Receipt), che include: Journal: output pubblico o risultati di impegno; Seal: una breve prova ZK verificabile on-chain o off-chain. Alla fine, i nodi sulla rete devono solo verificare questa ricevuta, senza dover rieseguire tutti i calcoli. In questo modo, il costo di "consenso globale" scende drasticamente da esecuzioni ripetute a verifica di prove brevi.