1/ De meeste ZK-provers zijn gebouwd om correcte bewijzen te produceren. Weinig zijn gebouwd om snel, controleerbaar en productie-klaar te zijn. Deel I introduceerde grafiek-eerst bewijzen. Deel II toonde de cijfers. Deel III is de roadmap om Venus in productie te krijgen. Welkom bij de finale van de zkVM-trilogie. 🧵

2/ Fase 1: Prestaties. We bouwen met de computationele grafiek – niet HAL – als de kern uitvoeringsinterface vanaf dag één. Vroege cudaGraph-integratie toont al 9–12% verbeteringen op RTX 5090. Doel: 15%+, met multi-GPU als volgende stap. Elke optimalisatie stapelt zich op.

3/ Fase 2: Beveiliging Dezelfde grafiek die de prestaties aandrijft, kan ook het bewijsprotocol zelf machinaal controleren. De belangrijkste inzicht: ZK-argumenttypes zijn klein en telbaar – SumCheck decomposeert in slechts twee. Bouw een eindige vertrouwde bibliotheek, verifieer elk protocol mechanisch.

4/ Fase 3: rbuilder-integratie. Blokbouw kan niet wachten op een trage prover. Dus we bouwen een asynchrone pijplijn met reorg-bewuste preemptie en een elegante terugval wanneer het bewijzen te lang duurt. Het doel: ZK-bewijzen die passen binnen de live blokproductie zonder deze te vertragen.

5/ Fase 4: Economie. Kan een zkEVM-knooppunt zichzelf in stand houden? We modelleren bewijsvergoedingen, MEV-aandeel en protocolincentives tegen hardware- en operationele kosten over 3 GPU-configuraties (van enkele RTX 5090 tot 8x) om het break-evenpunt te vinden. Graph-first wint alleen als het haalbaar is om te draaien.

6/ De meeste ZK-provers zijn gebouwd om correcte bewijzen te produceren. Correcte bewijzen zijn de basis. We bouwen er een die ook snel, controleerbaar, klaar voor productie en duurzaam in gebruik is. Dat is wat graph-first mogelijk maakt. Lees Deel III: