1/ Die meisten ZK-Prover sind darauf ausgelegt, korrekte Beweise zu erzeugen. Nur wenige sind darauf ausgelegt, schnell, prüfbar und produktionsbereit zu sein. Teil I führte in das graphenbasierte Beweisen ein. Teil II zeigte die Zahlen. Teil III ist der Fahrplan, um Venus in die Produktion zu bringen. Willkommen zum Finale der zkVM-Trilogie. 🧵

2/ Phase 1: Leistung. Wir bauen mit dem Berechnungsgraphen – nicht HAL – als die zentrale Ausführungsoberfläche von Anfang an. Die frühe cudaGraph-Integration zeigt bereits Verbesserungen von 9–12% auf der RTX 5090. Ziel: 15%+, wobei Multi-GPU als Nächstes bewiesen wird. Jede Optimierung kumuliert.

3/ Phase 2: Sicherheit Das gleiche Diagramm, das die Leistung antreibt, kann auch das Beweisprotokoll selbst maschinell überprüfen. Die zentrale Erkenntnis: ZK-Argumenttypen sind klein und zählbar – SumCheck zerfällt in nur zwei. Bauen Sie eine endliche vertrauenswürdige Bibliothek, um jedes Protokoll mechanisch zu überprüfen.

4/ Phase 3: rbuilder-Integration. Blockerstellung kann nicht auf einen langsamen Prover warten. Deshalb bauen wir eine asynchrone Pipeline mit reorg-bewusster Präemption und einem sanften Fallback, wenn das Beweisen überläuft. Das Ziel: ZK-Beweisführung, die in die laufende Blockproduktion passt, ohne sie zu verlangsamen.

5/ Phase 4: Wirtschaft. Kann ein zkEVM-Knoten sich selbst tragen? Wir modellieren die Gebühren für den Nachweis, den MEV-Anteil und die Protokollanreize im Vergleich zu Hardware- und Betriebskosten über 3 GPU-Konfigurationen (von einer einzelnen RTX 5090 bis 8x), um den Break-even-Punkt zu finden. Graph-first gewinnt nur, wenn es rentabel ist, ihn zu betreiben.

6/ Die meisten ZK-Prover sind darauf ausgelegt, korrekte Beweise zu erzeugen. Korrekte Beweise sind die Grundlage. Wir bauen einen, der auch schnell, prüfbar, produktionsbereit und nachhaltig im Betrieb ist. Das macht graph-first möglich. Lies Teil III: