Jatketaan graafipohjaisen zkVM:n kehittämistä, mutta haluamme ensin kysyä: Miksi HAL-tyyliset prover-arkkitehtuurit saavuttavat katon? Näemme kolme perustavanlaatuista vikaa, jotka rajoittavat suorituskykyä, turvallisuutta ja tulevaa laitteistotukea. 🧵

Vika #1: Ei globaalia optimointia HAL laukaisee ytimet yksi kerrallaan, piilottaen koko laskennan. Tämä estää: - Tehokas isäntälaitteiden↔datan siirto - Ytimien pakkaaminen CUDA-graafeihin - Todellinen datatason moni-GPU-rinnakkaisuus Tulos: raskas GPU–CPU-synkronointi ja alhainen käyttöaste.

Vika #2: Huono turvallisuus ja auditoitavuus Vahvat ZK-järjestelmät tarvitsevat selkeän näkyvyyden: - Fiat–Shamir-transkriptiovuorovaikutukset - Velvoitteiden ja IOP:n alennusten todistaminen Laskennallinen graafi voi kantaa tätä tietoa. HAL piilottaa sen mustan laatikon todistamisfunktioon.

Vika #3: Rajoittaa tulevaa laitteiston yhteissuunnittelua Uudet kiihdyttimet voivat natiivisti tukea todisteita (Fiat–Shamir, jälkien generointi jne.). Graafit voidaan kääntää uudelle laitteistolle, kun taas läpinäkymättömät prove()-funktiot eivät.

HAL oli käytännöllinen silta suorittimen ja näytönohjaimen välillä. Mutta pitkällä aikavälillä ZK-proversien ja zkVM:ien on oltava graafinatiivisia, jotta saavutetaan globaali optimointi, vahva auditoitavuus ja aito laitteisto/ohjelmisto-yhteissuunnittelu. ⚡️