1/ A maioria dos provadores ZK é construída para produzir provas corretas. Poucos são feitos para serem rápidos, auditáveis e prontos para produção. A Parte I introduziu a demonstração baseada em grafos. A Parte II mostrou os números. A Parte III é o roteiro para colocar Venus em produção. Bem-vindo ao final da Trilogia zkVM. 🧵

2/ Fase 1: Desempenho. Estamos construindo com o grafo computacional – não o HAL – como interface central de execução desde o primeiro dia. A integração inicial do cudaGraph já mostra melhorias de 9–12% em relação à RTX 5090. Alvo: 15%+, com multi-GPU sendo o próximo. Toda otimização se acumula.

3/ Fase 2: Segurança O mesmo desempenho que controla o gráfico também pode verificar o protocolo de prova em si. A principal ideia: os tipos de argumentos ZK são pequenos e enumeráveis – o SumCheck se decompõe em apenas dois. Construa uma biblioteca confiável finita, verifique qualquer protocolo mecanicamente.

4/ Fase 3: integração com rbuilder. Quem construiu blocos mal pode esperar por um prover lento. Então estamos construindo um pipeline assíncrono com preempção consciente do reorganização e um recuo elegante quando a prova é ultrapassada. O objetivo: ZK provar que isso se encaixa dentro da produção de blocos vivos sem desacelerar.

5/ Fase 4: Economia. Um nó zkEVM pode se sustentar sozinho? Estamos modelando taxas de prova, participação do MEV e incentivos de protocolo contra custos de hardware e operações em 3 configurações de GPU (de uma RTX 5090 a 8x) para encontrar o ponto de equilíbrio. O primeiro no grafo só vence se for viável de executar.

6/ A maioria dos provadores ZK é construída para produzir provas corretas. Provas corretas são a base. Estamos construindo um que também seja rápido, auditável, pronto para produção e sustentável de operar. É isso que o gráfico em primeiro lugar possibilita. Leia a Parte III: