1/ La mayoría de los probadores ZK están diseñados para producir demostraciones correctas. Pocas están diseñadas para ser rápidas, auditables y listas para producción. La Parte I introdujo la demostración basada en grafos. La Parte II mostró los números. La Parte III es la hoja de ruta para poner Venus en producción. Bienvenidos al final de la trilogía zkVM. 🧵

2/ Fase 1: Rendimiento. Estamos construyendo con el grafo computacional – no HAL – como interfaz central de ejecución desde el primer día. La integración temprana de CudaGraph ya muestra mejoras del 9–12% respecto a la RTX 5090. Objetivo: 15%+, con multiGPU como siguiente. Cada optimización se compone.

3/ Fase 2: Seguridad El mismo grafo que impulsa el rendimiento también puede verificar por máquina el propio protocolo de prueba. La idea clave: los tipos de argumentos ZK son pequeños e enumerables: SumCheck se descompone en solo dos. Construye una biblioteca de confianza finita, verifica cualquier protocolo mecánicamente.

4/ Fase 3: integración con rbuilder. La construcción de bloques no puede esperar a que llegue un prover lento. Así que estamos construyendo una pipeline asíncrona con preeminencia consciente de la reorganización y un respaldo elegante cuando la prueba se apaga. El objetivo: ZK demuestre que encaja dentro de la producción de bloques vivos sin ralentizarla.

5/ Fase 4: Economía. ¿Puede un nodo zkEVM sostenerse solo? Estamos modelando las tasas de prueba, la cuota MEV e incentivos de protocolo contra costes de hardware y operaciones en 3 configuraciones de GPU (desde una sola RTX 5090 hasta 8x) para encontrar el punto de equilibrio. El que se enfoca primero solo gana si es viable de ejecutar.

6/ La mayoría de los probadores ZK están diseñados para producir demostraciones correctas. Las demostraciones correctas son la base. Estamos construyendo uno que también sea rápido, auditable, listo para producción y sostenible de gestionar. Eso es lo que hace posible el enfoque primero en el grafo. Lee la Parte III: