1/ Większość proverów ZK jest zaprojektowana do generowania poprawnych dowodów. Niewiele z nich jest zaprojektowanych, aby być szybkie, audytowalne i gotowe do produkcji. Część I wprowadziła dowodzenie oparte na grafach. Część II pokazała liczby. Część III to mapa drogowa, aby wprowadzić Venus do produkcji. Witamy w finale trylogii zkVM. 🧵

2/ Faza 1: Wydajność. Budujemy z grafem obliczeniowym – a nie HAL – jako podstawowym interfejsem wykonawczym od pierwszego dnia. Wczesna integracja cudaGraph już pokazuje poprawy o 9–12% na RTX 5090. Cel: 15%+, z wieloma GPU jako następny krok. Każda optymalizacja się kumuluje.

3/ Faza 2: Bezpieczeństwo Ten sam wykres napędzający wydajność może również maszynowo sprawdzić sam protokół dowodowy. Kluczowy wniosek: typy argumentów ZK są małe i zliczalne – SumCheck rozkłada się na zaledwie dwa. Zbuduj skończoną zaufaną bibliotekę, zweryfikuj dowolny protokół mechanicznie.

4/ Faza 3: integracja rbuilder. Budowanie bloków nie może czekać na wolnego dowodzącego. Dlatego budujemy asynchroniczny pipeline z preempcją świadomą reorganizacji i łagodnym przejściem, gdy dowodzenie trwa zbyt długo. Cel: dowodzenie ZK, które mieści się w produkcji bloków na żywo, nie spowalniając jej.

5/ Faza 4: Ekonomia. Czy węzeł zkEVM może się utrzymać? Modelujemy opłaty za dowody, udział w MEV oraz zachęty protokołu w stosunku do kosztów sprzętu i operacyjnych w trzech konfiguracjach GPU (od pojedynczego RTX 5090 do 8x), aby znaleźć punkt rentowności. Graph-first wygrywa tylko wtedy, gdy jest opłacalne uruchomienie.

6/ Większość proverów ZK jest zaprojektowana do generowania poprawnych dowodów. Poprawne dowody są podstawą. Budujemy taki, który jest również szybki, audytowalny, gotowy do produkcji i zrównoważony w działaniu. To, co umożliwia podejście oparte na grafach.