1/ La mayoría de los probadores ZK están diseñados para producir pruebas correctas. Pocos están diseñados para ser rápidos, auditables y listos para producción. La Parte I introdujo la prueba basada en gráficos. La Parte II mostró los números. La Parte III es la hoja de ruta para llevar a Venus a producción. Bienvenido al final de la trilogía zkVM. 🧵

2/ Fase 1: Rendimiento. Estamos construyendo con el grafo computacional – no HAL – como la interfaz de ejecución central desde el primer día. La integración temprana de cudaGraph ya muestra mejoras del 9 al 12% en RTX 5090. Objetivo: 15% o más, con la prueba de múltiples GPU a continuación. Cada optimización se acumula.

3/ Fase 2: Seguridad El mismo gráfico que impulsa el rendimiento también puede verificar mecánicamente el protocolo de prueba en sí. La clave: los tipos de argumentos ZK son pequeños y enumerables: SumCheck se descompone en solo dos. Construir una biblioteca confiable finita, verificar cualquier protocolo mecánicamente.

4/ Fase 3: integración de rbuilder. La construcción de bloques no puede esperar a un probador lento. Así que estamos construyendo un pipeline asíncrono con preempción consciente de reorganización y un retroceso elegante cuando la prueba se extiende. El objetivo: prueba ZK que se ajuste a la producción de bloques en vivo sin ralentizarla.

5/ Fase 4: Economía. ¿Puede un nodo zkEVM mantenerse por sí mismo? Estamos modelando las tarifas de prueba, la participación de MEV y los incentivos del protocolo en comparación con los costos de hardware y operaciones en 3 configuraciones de GPU (desde una sola RTX 5090 hasta 8x) para encontrar el punto de equilibrio. Graph-first solo gana si es viable de ejecutar.

6/ La mayoría de los ZK provers están diseñados para producir pruebas correctas. Las pruebas correctas son la base. Estamos construyendo uno que también sea rápido, auditable, listo para producción y sostenible de operar. Eso es lo que hace posible un enfoque centrado en gráficos. Lee la Parte III: