Gespecialiseerde ZK vs. algemene ZK: Wat is de toekomst?

Specialisatie en generalisatie, wat is de toekomst van ZK? Laat me proberen deze vraag te beantwoorden met een diagram:

Gespecialiseerde ZK vs. Algemene ZK

Zoals het diagram laat zien, is het voor ons mogelijk om in de toekomst te convergeren naar een magisch optimaal punt op het trade-off coördinatenstelsel?

Nee, de toekomst van off-chain verifieerbare berekeningen is een continue curve die de grenzen tussen gespecialiseerde en algemene ZK doet vervagen. Sta me toe om de historische evolutie van deze termen uit te leggen en hoe ze in de toekomst zullen convergeren.

Twee jaar geleden betekende “gespecialiseerde” ZK-infrastructuur low-level circuitframeworks zoals circom, Halo2 en arkworks. ZK toepassingen gebouwd met deze raamwerken waren in wezen handgeschreven ZK circuits. Ze waren snel en kosteneffectief voor specifieke taken, maar meestal moeilijk te ontwikkelen en te onderhouden. Ze zijn verwant aan verschillende gespecialiseerde geïntegreerde circuit chips (fysieke silicium wafers) in de huidige IC industrie, zoals NAND chips en controller chips.

De afgelopen twee jaar is de gespecialiseerde ZK-infrastructuur echter geleidelijk algemener geworden.

We hebben nu ZKML, ZK coprocessor en ZKSQL raamwerken die eenvoudig te gebruiken en zeer programmeerbare SDK’s bieden voor het bouwen van verschillende categorieën ZK toepassingen zonder ook maar één regel ZK circuitcode te schrijven. De ZK coprocessor maakt het bijvoorbeeld mogelijk voor slimme contracten om zonder vertrouwen toegang te krijgen tot historische staten, gebeurtenissen en transacties van de blockchain en om willekeurige berekeningen uit te voeren op deze gegevens. ZKML stelt slimme contracten in staat om AI-inferentieresultaten op een vertrouwenloze manier te gebruiken om een breed scala aan machine-learningmodellen te verwerken.

Deze geëvolueerde raamwerken verbeteren de programmeerbaarheid in hun doeldomeinen aanzienlijk terwijl ze hoge prestaties en lage kosten behouden dankzij dunne abstractielagen (SDK/API) die dicht in de buurt komen van bare-metal circuits.

Ze zijn verwant aan GPU, TPU en FPGA in de IC-markt: programmeerbare domeinspecialisten.

ZKVM heeft de afgelopen twee jaar ook grote vooruitgang geboekt. Met name alle algemene ZKVM’s zijn gebouwd bovenop low-level, gespecialiseerde ZK frameworks. Het idee is dat je ZK applicaties kunt schrijven in hoog-niveau talen (nog gebruikersvriendelijker dan SDK/API), die compileren in een combinatie van gespecialiseerde circuits en instructiesets (RISC-V of vergelijkbaar met WASM). Ze zijn als CPU-chips in de IC-industrie.

ZKVM is een abstractielaag boven low-level ZK raamwerken, net als ZK coprocessors.

Zoals een wijs persoon ooit zei: een abstractielaag kan alle problemen in de informatica oplossen, maar creëert tegelijkertijd een ander probleem. Afwegingen, daar gaat het om. In principe ruilen we voor ZKVM prestaties en algemeenheid.

Twee jaar geleden was de “bare-metal” prestatie van ZKVM inderdaad slecht. In slechts twee jaar tijd is de prestatie van ZKVM echter aanzienlijk verbeterd.

Waarom?

Omdat deze “general-purpose” ZKVM’s meer “gespecialiseerd” zijn geworden. Een belangrijke reden voor de prestatieverbetering is “precompilatie”. Deze precompilaties zijn gespecialiseerde ZK circuits die in staat zijn om algemene high-level programma’s, zoals SHA2 en verschillende handtekeningverificaties, veel sneller te berekenen dan ze op te splitsen in instructiecircuitfragmenten.

De trend is nu dus heel duidelijk.

Gespecialiseerde ZK-infrastructuur wordt algemener, terwijl algemene ZKVM’s steeds gespecialiseerder worden.

De optimalisaties van beide oplossingen in de afgelopen jaren hebben een beter afwegingspunt bereikt dan voorheen: vooruitgang boeken op het ene punt zonder het andere op te offeren. Daarom hebben beide partijen het gevoel dat “we absoluut de toekomst hebben”.

De wijsheid van de computerwetenschap vertelt ons echter dat we op een gegeven moment de “Pareto optimale muur” (groene stippellijn) tegenkomen, waar we de ene prestatie niet kunnen verbeteren zonder een andere op te offeren.

Daarom rijst de miljoen dollar vraag:

Zal de ene technologie de andere volledig vervangen op het juiste moment?

Om inzichten te lenen uit de IC-industrie: de CPU-markt is 126 miljard dollar groot, terwijl de hele IC-industrie (inclusief alle “gespecialiseerde” IC’s) 515 miljard dollar groot is. Ik ben ervan overtuigd dat, vanuit microperspectief, de geschiedenis zich hier zal herhalen en dat ze elkaar niet zullen vervangen.

Dat gezegd hebbende, vandaag de dag zou niemand zeggen: “Hé, ik gebruik een computer die volledig wordt aangedreven door een CPU voor algemene doeleinden” of “Hé, dit is een chique robot die wordt aangedreven door gespecialiseerde IC’s”.

Ja, we moeten deze kwestie inderdaad vanuit een macroperspectief bekijken en in de toekomst zal er een afruilcurve zijn waarbij ontwikkelaars flexibel kunnen kiezen op basis van hun behoeften.

In de toekomst kunnen gespecialiseerde ZK-infrastructuur en algemene ZKVM samenwerken. Dit kan op verschillende manieren worden gerealiseerd. De eenvoudigste methode is nu al haalbaar. Je kunt bijvoorbeeld een ZK coprocessor gebruiken om enkele berekeningsresultaten te genereren in de transactiegeschiedenis van de blockchain, maar de bedrijfslogica voor berekeningen op deze gegevens is erg complex en kan niet eenvoudig worden uitgedrukt in de SDK/API.

Wat je kunt doen is het verkrijgen van krachtige en goedkope ZK bewijzen van de gegevens en tussenliggende rekenresultaten, en deze dan samenvoegen in een VM voor algemeen gebruik door middel van recursieve bewijzen.

Hoewel ik dit soort debatten interessant vind, weet ik dat we allemaal bouwen aan deze toekomst van asynchroon computergebruik, gedreven door off-chain verifieerbare berekeningen voor blockchain. Naarmate er in de komende jaren gebruikscases voor massale adoptie door gebruikers ontstaan, denk ik dat dit debat eindelijk tot een conclusie zal komen.