1/ La plupart des ZK provers sont conçus pour produire des preuves correctes. Peu sont conçus pour être rapides, audités et prêts pour la production. La Partie I a introduit la preuve axée sur les graphes. La Partie II a montré les chiffres. La Partie III est la feuille de route pour mettre Venus en production. Bienvenue à la finale de la trilogie zkVM. 🧵

2/ Phase 1 : Performance. Nous construisons avec le graphe de calcul – pas HAL – comme interface d'exécution principale dès le premier jour. L'intégration précoce de cudaGraph montre déjà des améliorations de 9 à 12 % sur RTX 5090. Objectif : 15 % ou plus, avec la validation multi-GPU à suivre. Chaque optimisation s'accumule.

3/ Phase 2 : Sécurité Le même graphique qui pilote la performance peut également vérifier mécaniquement le protocole de preuve lui-même. L'idée clé : les types d'arguments ZK sont petits et énumérables – SumCheck se décompose en seulement deux. Construisez une bibliothèque de confiance finie, vérifiez mécaniquement tout protocole.

4/ Phase 3 : intégration de rbuilder. La construction de blocs ne peut pas attendre un prouveur lent. Nous construisons donc un pipeline asynchrone avec préemption consciente des réorganisations et un retour en arrière gracieux lorsque la preuve dépasse le temps imparti. L'objectif : une preuve ZK qui s'intègre dans la production de blocs en direct sans la ralentir.

5/ Phase 4 : Économie. Un nœud zkEVM peut-il se soutenir ? Nous modélisons les frais de preuve, la part de MEV et les incitations du protocole par rapport aux coûts matériels et opérationnels sur 3 configurations GPU (d'un seul RTX 5090 à 8x) pour trouver le point d'équilibre. Graph-first ne gagne que s'il est viable de fonctionner.

6/ La plupart des ZK provers sont conçus pour produire des preuves correctes. Les preuves correctes sont la norme. Nous en construisons un qui est également rapide, auditable, prêt pour la production et durable à exécuter. C'est ce que permet une approche axée sur le graphe. Lisez la Partie III :