1/ Většina ZK proverérů je navržena tak, aby produkovala správné důkazy. Jen málo z nich je navrženo tak, aby bylo rychlé, auditovatelné a připravené na produkci. Část I představila dokazování s principem grafu jako prvního. Část II ukazovala čísla. Třetí část je plán, jak dostat Venuši do výroby. Vítejte u finále trilogie zkVM. 🧵

2/ Fáze 1: Výkon. Stavíme na výpočetním grafu – nikoli HAL – jako hlavním rozhraním pro provádění od prvního dne. Raná integrace cudaGraph již ukazuje zlepšení o 9–12 % oproti RTX 5090. Cíl: 15 %+, s dalším důkazem multi-GPU. Každá optimalizace se skládá.

3/ Fáze 2: Bezpečnost Stejný graf řídící výkon může také strojově kontrolovat samotný protokol důkazu. Klíčový poznatek: Typy argumentů ZK jsou malé a vyčíslitelné – SumCheck se rozkládá pouze na dva. Vytvořte konečnou důvěryhodnou knihovnu, ověřte jakýkoli protokol mechanicky.

4/ Fáze 3: integrace rbuilderu. Stavba bloků se nemůže dočkat pomalého ověření. Takže budujeme asynchronní pipeline s reorganizací citlivou předem a elegantní záložní možností při překročení průběhů dokazování. Cíl: ZK dokázat, že to zapadne do živé blokové produkce, aniž by ji zpomalovalo.

5/ Fáze 4: Ekonomie. Může se uzel zkEVM udržet sám? Modelujeme poplatky za důkaz, podíl MEV a pobídky protokolů proti nákladům na hardware a provoz napříč třemi konfiguracemi GPU (od jednoho RTX 5090 po 8x), abychom našli bod zvratu. Graph-first vyhrává jen tehdy, pokud je možné ho spustit.

6/ Většina ZK proverérů je navržena tak, aby produkovala správné důkazy. Správné důkazy jsou základem. Stavíme takovou, která je zároveň rychlá, auditovatelná, připravená na produkci a udržitelná k provozu. To je to, co graf-first umožňuje. Přečtěte si část III: