1/ La maggior parte dei prover ZK sono progettati per produrre prove corrette. Pochi sono progettati per essere veloci, auditabili e pronti per la produzione. La Parte I ha introdotto la dimostrazione basata su grafi. La Parte II ha mostrato i numeri. La Parte III è la roadmap per portare Venus in produzione. Benvenuti al finale della trilogia zkVM. 🧵

2/ Fase 1: Prestazioni. Stiamo costruendo con il grafo computazionale – non HAL – come interfaccia di esecuzione principale fin dal primo giorno. L'integrazione precoce di cudaGraph mostra già miglioramenti del 9–12% su RTX 5090. Obiettivo: 15%+, con la prova multi-GPU successiva. Ogni ottimizzazione si accumula.

3/ Fase 2: Sicurezza Lo stesso grafico che guida le prestazioni può anche controllare meccanicamente il protocollo di prova stesso. L'intuizione chiave: i tipi di argomenti ZK sono piccoli e numerabili – SumCheck si decompone in soli due. Costruisci una libreria fidata finita, verifica qualsiasi protocollo meccanicamente.

4/ Fase 3: integrazione di rbuilder. La costruzione dei blocchi non può aspettare un prover lento. Quindi stiamo costruendo una pipeline asincrona con preemption consapevole della riorganizzazione e un fallback elegante quando la prova supera il tempo. L'obiettivo: prova ZK che si inserisce nella produzione di blocchi dal vivo senza rallentarla.

5/ Fase 4: Economia. Un nodo zkEVM può sostenersi? Stiamo modellando le commissioni di prova, la quota di MEV e gli incentivi del protocollo rispetto ai costi hardware e operativi su 3 configurazioni GPU (da una singola RTX 5090 a 8x) per trovare il punto di pareggio. Il grafico-primo vince solo se è fattibile eseguire.

6/ La maggior parte dei prover ZK sono progettati per produrre prove corrette. Le prove corrette sono la base. Stiamo costruendo uno che sia anche veloce, verificabile, pronto per la produzione e sostenibile da gestire. Questo è ciò che rende possibile un approccio grafico.