Pojďme pokračovat v rozvíjení grafově založeného zkVM, ale nejdřív se chceme zeptat: Proč architektury ve stylu HAL narazí na strop? Vidíme tři zásadní vady, které omezují výkon, bezpečnost a budoucí podporu hardwaru. 🧵

Vada #1: Žádná globální optimalizace HAL spouští jádra jedno po druhém, čímž skrývá celý výpočet. To blokuje: - Efektivní↔pohyb dat hostitelského zařízení - Balení jader do CUDA grafů - Pravý datový paralelismus s více GPU Výsledek: silná synchronizace GPU a CPU a nízké využití.

Vada #2: Špatná bezpečnost a auditovatelnost Silné ZK systémy potřebují explicitní přehled v: - Interakce přepisů Fiat–Shamir - Prokazování povinností a snížení IOP Výpočetní graf může tyto informace nést. HAL ji skrývá uvnitř černé skříňky proproof() funkce.

Vada #3: Omezuje budoucí spolunávrh hardwaru Vznikající akcelerátory mohou nativně podporovat části ověřování (Fiat–Shamir, generování stop atd.). Grafy lze převést do nového hardwaru, zatímco neprůhledné funkce proproof() ne.

HAL byl praktický most mezi CPU a GPU. Dlouhodobě však musí být ZK provers a zkVM grafově nativní, aby bylo možné dosáhnout globální optimalizace, silné auditovatelnosti a skutečného hardwarovo-softwarového spolunávrhu. ⚡️