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

2/ Fase 1: Desempenho. Estamos a construir com o grafo computacional – não HAL – como a interface de execução central desde o primeiro dia. A integração inicial do cudaGraph já mostra melhorias de 9–12% na RTX 5090. Objetivo: 15%+, com a prova de multi-GPU a seguir. Cada otimização se acumula.

3/ Fase 2: Segurança O mesmo gráfico que impulsiona o desempenho também pode verificar mecanicamente o próprio protocolo de prova. A principal percepção: 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 do rbuilder. A construção de blocos não pode esperar por um provador lento. Portanto, estamos construindo um pipeline assíncrono com pré-empcão ciente de reorganização e fallback gracioso quando a prova ultrapassa o tempo. O objetivo: prova ZK que se encaixa na produção de blocos ao vivo sem desacelerá-la.

5/ Fase 4: Economia. Um nó zkEVM pode sustentar-se? Estamos a modelar taxas de prova, participação de MEV e incentivos de protocolo em relação aos custos de hardware e operações em 3 configurações de GPU (desde uma única RTX 5090 até 8x) para encontrar o ponto de equilíbrio. A abordagem gráfica só vence se for viável de executar.

6/ A maioria dos provers ZK são construídos para produzir provas corretas. Provas corretas são a base. Estamos a construir um que também é rápido, auditável, pronto para produção e sustentável para operar. É isso que o enfoque em gráficos torna possível. Leia a Parte III: