En utviklerveiledning til zkGalaxy

Dette er en ekstremt nyttig heuristikk for å differensiere tilnærminger for å støtte en zkEVM. Imidlertid er zkEVM-er en undergruppe av alle mulige måter å bygge nullkunnskapsapplikasjoner på. For en programmerer som ønsker å utnytte de unike egenskapene til zk-beregning, nemlig kortfattethet, null kunnskap og korrekthet, en zkEVM er kanskje ikke det beste valget. Ved å legge ut hele settet med utviklerverktøy, håper jeg å gi en veiledning som hjelper i beslutningsprosessen rundt riktig zk-stabel for applikasjonen din.

I løpet av det siste året eller to har det vært en enorm fremgang innen zk-verktøy. De nærmer seg et punkt der vanlige programvareutviklere kan utnytte de kraftige egenskapene til zk uten en dyp forståelse av den skremmende underliggende matematikken og ingeniørkunsten. På den andre enden har det vært en spredning av verktøy for superbrukere som gir zk-eksperter ekstremt fin kontroll over zk-stakken.

Moderne programvare er bygget på utallige lag med abstraksjon for å maksimere spesialistproduktiviteten. Det er mange fordeler med abstraksjon i engineering som er litt intuitive – en webutvikler trenger ikke å forstå hvordan operativsystemer fungerer i dybden. 

Nøkkelen til å bygge gode, gjenbrukbare abstraksjonslag er å kapsle inn kompleksiteten til et lag og deretter gi enkle, men uttrykksfulle grensesnitt for lag høyere i stabelen som kan brukes. Gjøres det riktig, gjør dette det mulig for utviklere med ulike områder av ekspertise og kunnskap å bygge nyttige verktøy på tvers av stabelen.

Til ingen overraskelse gjelder de samme prinsippene for zk-systemer, og disse abstraksjonslagene er i ferd med å bli modne nok til at en zk-nybegynner kan begynne å bruke dem og bygge applikasjoner i dag.

Arkworks-rs er et økosystem av Rust-biblioteker som gir effektive og sikre implementeringer av underkomponentene til en zkSNARK-applikasjon. Arkworks tilbyr grensesnittene som er nødvendige for utviklere for å tilpasse programvarestabelen for en zk-applikasjon uten å måtte implementere fellestrekk med andre eksisterende biblioteker på nytt.

Før Arkworks var den eneste måten å lage en ny zk-applikasjon på å bygge alt fra bunnen av. De viktigste fordelene med Arkworks-rs fremfor spesialbygde, vertikalt integrerte verktøy er fleksibilitetsnivået, reduksjonen i duplisert konstruksjon og reduksjonen i revisjonsinnsatsen. Arkworks' fornuftige grensesnittlinjer mellom komponentene gir mulighet for et tempo med oppgradering som kan holde stabelen relevant midt i det voldsomme innovasjonstakten innen zk-teknologier, uten å tvinge teamene til å gjenoppbygge alt fra bunnen av.

Arkworks er for prosjekter som trenger fin kontroll over hele zk-programvarestabelen, men som ikke ønsker å bygge alle de overflødige brikkene fra bunnen av. Hvis du vurderer en tilpasset versjon av en DSL-krets fordi du for eksempel lager et nytt bevissystem, men er usikker på forpliktelsesskjemaet eller den tilsvarende elliptiske kurven, vil arkworks tillate deg å raskt bytte mellom flere alternativer med delte grensesnitt, heller enn å starte fra bunnen av.

For å lage et bevis på en eller annen beregning, må først denne beregningen uttrykkes i en form som et zkSNARK-system kan forstå. Flere domenespesifikke språk har laget programmeringsspråk som lar applikasjonsutviklere uttrykke sine beregninger på en slik måte. Disse inkluderer Aztec Noir, Starknets Kairo, Circom, ZoKrates, og Aleos Leo blant andre. Det underliggende bevissystemet og matematiske detaljer er vanligvis ikke eksponert for applikasjonsutvikleren.

zkApp-utviklere må bli dyktige i å skrive programmene sine på domenespesifikke språk. Noen av disse språkene ligner mye på kjente programmeringsspråk, mens andre kan være ganske vanskelige å lære. La oss bryte ned noen av disse:

Kairo – Starkware DSL nødvendig for å bygge apper på Starknet. Kompilerer ned til Kairo-spesifikt assembly-språk som kan tolkes av Cairo zkVM.

ZoKrates — ZoKrates er et verktøysett for vanlige SNARK-behov, inkludert et språk på høyt nivå for å skrive kretser. ZoKrates har også en viss fleksibilitet rundt kurvene, bevisskjemaet og backend, noe som lar utviklere hot-swap med enkle CLI-argumenter.

Circom — Circom er et spesialbygget språk for å konstruere kretser. Foreløpig er det de-facto-språket for kretser i produksjon. Språket er ikke spesielt ergonomisk. Språket i seg selv gjør deg svært oppmerksom på det faktum at du skriver kretser.

Leo — Leo ble utviklet som språket for Aleo-blokkjeden. Leo har en viss rustlignende syntaks og er spesielt laget for tilstandsoverganger inne i en blokkjede.

Noir – Rustinspirert syntaks. Arkitektert rundt IR i stedet for selve språket, noe som betyr at det kan ha en vilkårlig frontend. 

Enhver applikasjonsutvikler som ønsker å dra nytte av de unike egenskapene til zk i sin applikasjon. Noen av disse språkene har blitt kamptestet med milliarder av dollar på tvers av dem via kjeder som ZCash og Starknet. Selv om noen av prosjektene vi vil diskutere ikke er helt klare for produksjonsbruk, er det for øyeblikket den beste strategien å skrive kretsene dine på et av disse språkene, med mindre du trenger de finere kontrollene som et verktøysett som Arkworks gir.

Det primære målet med en zkEVM er å ta en Ethereum-tilstandsovergang og bevise dens gyldighet ved å bruke et kortfattet bevis på null kunnskap på korrekthet. Som nevnt i Vitaliks innlegg, er det en rekke måter å gjøre dette på med subtile forskjeller og tilsvarende avveininger. 

Den viktigste tekniske forskjellen mellom alle disse er nøyaktig hvor i språkstabelen beregningen konverteres til en form (aritmetisering) som kan brukes i et bevissystem. I noen zkEVM-er skjer dette på høynivåspråkene (Solidity, Vyper, Yul), mens andre tilnærminger prøver å bevise EVM-en helt til opkodenivået. Avveiningene mellom disse tilnærmingene ble dekket dypt i Vitaliks innlegg, men jeg vil oppsummere det i én setning: Jo lavere konverteringen/aritmetiseringen skjer i stabelen, desto større blir ytelsesstraffen.

Hovedutfordringen med å lage bevis for en virtuell maskin er at størrelsen på kretsen vokser proporsjonalt med størrelsen på ALLE mulige instruksjoner for hver utførte instruksjon. Dette skjer fordi kretsen ikke vet hvilke instruksjoner som vil bli utført i hvert program, så den må støtte dem alle.

Hva dette betyr i praksis er at du betaler (i ytelseskostnad) for den dyreste mulige instruksjonen, selv når du kun utfører den enkleste instruksjonen. Dette fører til en direkte avveining mellom generaliserbarhet og ytelse – ettersom du legger til flere instruksjoner for generaliserbarhet, betaler du for dette på hver instruksjon du beviser!

Dette er et grunnleggende problem med universelle kretser, men med ny utvikling innen teknologi som IVC (incremental verifiable compute), kan denne begrensningen forbedres ved å dele opp beregningen i mindre biter som hver har spesialiserte, mindre underkretser.

Dagens zkEVM-implementeringer bruker forskjellige strategier for å dempe virkningen av dette problemet... For eksempel river zkSync ut de dyrere operasjonene (for det meste kryptografiske forhåndskompileringer som hashes og ECDSA) fra hovedkretsen for utførelsesprøve til separate kretser som er aggregert sammen på slutt via snarrekursjon. zkSync tok denne tilnærmingen etter at de innså at størstedelen av kostnadene deres kom fra noen få komplekse instruksjoner.

Grunnen til at det er dyrere å bevise et mer EVM-ekvivalent instruksjonssett er at EVM ikke ble designet for zk-beregninger. Ved å forlate EVM tidligere i stabelen kan zkEVM-er kjøre på instruksjonssett som er mer optimalisert for zk, og dermed billigere å bevise.

De ideelle kundene for en zkEVM er smarte kontraktsapplikasjoner som trenger størrelsesordener billigere transaksjoner enn det som er tilgjengelig på L1 Ethereum. Disse utviklerne har ikke nødvendigvis ekspertisen eller båndbredden til å skrive zk-applikasjoner fra bunnen av. Derfor foretrekker de å skrive søknadene sine på språk på høyere nivå de er kjent med, som Solidity. 

Skalering av Ethereum er for tiden den mest etterspurte applikasjonen av zk-teknologi.

En zkEVM er en Ethereum-skaleringsløsning som friksjonsfritt reduserer overbelastningsproblemet som begrenser L1 dApp-utviklere.

Målet med en zkEVM er å støtte en utvikleropplevelse som er så nær som mulig dagens Ethereum-utvikling. Full Solidity-støtte betyr at team ikke trenger å bygge og vedlikeholde flere kodebaser. Dette er noe upraktisk å gjøre perfekt fordi zkEVM-er må bytte ut en viss kompatibilitet for å kunne generere bevis av rimelig størrelse i løpet av rimelig tid.

Den primære forskjellen mellom zkSync og Scroll er hvor/når i stabelen de utfører aritmetisering – det vil si hvor de konverterer fra vanlige EVM-konstruksjoner til en SNARK-vennlig representasjon. For zkSync skjer dette når de konverterer YUL-bytekoden til sitt eget tilpassede zk-instruksjonssett. For Scroll skjer dette på slutten, når selve utførelsessporet genereres med faktiske EVM-opkoder.

Så for zkSync er alt det samme som å samhandle med EVM til zk-bytekoden er generert. For Scroll er alt det samme inntil den faktiske bytekoden blir utført. Dette er en subtil forskjell, som bytter ytelse mot støtte. For eksempel vil ikke zkSync støtte EVM-bytekodeverktøy som en debugger ut av esken, fordi det er en helt annen bytekode. Mens Scroll vil ha vanskeligere med å få god ytelse ut av et instruksjonssett, var det ikke designet for zk. Det er fordeler og ulemper med begge strategiene, og til syvende og sist er det mange eksogene faktorer som vil påvirke deres relative suksess.

???? Til tross for navngivningen er ikke LLVM en VM (virtuell maskin). LLVM er navnet på et sett med kompilatorverktøy som er forankret av en mellomrepresentasjon (IR) som er språkagnostisk.

=null; Foundation (om navnet, det er en SQL-injeksjon spøk hvis du lurer) bygger en kompilator som kan konvertere et hvilket som helst LLVM-frontend-språk til en mellomrepresentasjon som kan bevises i en SNARK. zkLLVM er bygget som en utvidelse av den eksisterende LLVM-infrastrukturen, en industristandard verktøykjede som støtter mange høynivåspråk som Rust, C, C++ osv.

En bruker som ønsker å bevise en eller annen beregning vil ganske enkelt implementere den beregningen i C++. zkLLVM tar denne høynivåkildekoden som støttes av deres modifiserte clang-kompilator (for tiden C++) og genererer en mellomrepresentasjon av kretsen. På dette tidspunktet er kretsen klar til å bli bevist, men brukeren vil kanskje bevise kretsen basert på noen dynamiske innganger. For å håndtere dynamiske innganger har zkLLVM en ekstra komponent referert til som tildeler, som genererer en tilordningstabell med alle innganger og vitner fullstendig forhåndsbehandlet og klar til å bli bevist sammen med kretsen.

Disse 2 komponentene er alt som er nødvendig for å generere et bevis. En bruker kan teoretisk generere et bevis selv, men siden dette er en noe spesialisert beregningsoppgave, vil de kanskje betale noen andre, som har maskinvaren, for å gjøre det for dem. For denne motpartens oppdagelsesmekanisme, =nul; Foundation har også etablert et "bevismarked" der bevisere kjemper for å bevise beregninger for brukere som vil betale dem for å gjøre det. Denne frie markedsdynamikken vil føre til at bevisere optimaliserer de mest verdifulle bevisoppgavene.

Siden hver beregningsoppgave som skal bevises er unik og genererer en annen krets, er det et uendelig antall kretser som bevisere må kunne håndtere. Denne tvungne generaliserbarheten gjør optimalisering av individuelle kretser vanskelig. Innføringen av et bevismarked tillater spesialisering på de kretsene som markedet anser som verdifulle. Uten dette markedet ville det vært utfordrende å overbevise en tester om å optimalisere denne kretsen på grunn av dette naturlige kaldstartproblemet.

Den andre avveiningen er den klassiske abstraksjonen vs. kontroll. Brukere som er villige til å ta dette brukervennlige grensesnittet gir opp kontrollen over de underliggende kryptografiske primitivene. For mange brukere er dette en svært gyldig avveining å ta, siden det ofte er bedre å la kryptografiekspertene ta disse avgjørelsene for deg.

En zkVM beskriver supersettet til alle zk virtuelle maskiner, mens en zkEVM er en spesifikk type zkVM, som var verdt å diskutere som et eget emne på grunn av dens utbredelse i dag. Det er noen få andre prosjekter som jobber med å bygge mer generaliserte zkVM-er som er basert på ISA-er i tillegg til skreddersydde krypto-VM-er.

I stedet for å bevise EVM, kan systemet bevise en annen instruksjonssettarkitektur (ISA), for eksempel RISC-V eller WASM i en ny VM. To prosjekter som jobber med disse generaliserte zkVM-ene er RISC Zero og zkWASM. La oss dykke litt ned i RISC Zero her for å demonstrere hvordan denne strategien fungerer og noen av dens fordeler/ulemper. 

RISC Zero er i stand til å bevise enhver beregning som utføres på en RISC-V-arkitektur. RISC-V er en åpen kildekode-standard for instruksjonssettarkitektur (ISA) som har blitt stadig mer populær. RISC-filosofien (reduced instruction set computer) er å bygge et ekstremt enkelt instruksjonssett med minimal kompleksitet. Dette betyr at utviklerne på de høyere lagene i stabelen ender opp med å ta på seg en større belastning med å implementere instruksjoner ved å bruke denne arkitekturen samtidig som de gjør maskinvareimplementeringen enklere.

Denne filosofien gjelder også for generell databehandling, ARM-brikker har utnyttet instruksjonssett i RISC-stil og har begynt å dominere markedet for mobile brikker. Det viser seg at de enklere instruksjonssettene også har større energi- og dysearealeffektivitet.

Denne analogien holder ganske bra for effektiviteten av å generere zk-bevis. Som diskutert tidligere, når du beviser et utførelsesspor i zk, betaler du for summen av kostnadene for alle instruksjoner per hvert element i sporet, så enklere og færre totale instruksjoner er bedre.

Fra et utviklerperspektiv er bruk av RISC Zero for å håndtere zk-bevis mye som å bruke AWS Lambda-funksjoner for å håndtere backend-serverarkitektur. Utviklere samhandler med RISC Zero eller AWS Lambda ved ganske enkelt å skrive kode, og tjenesten håndterer all backend-kompleksiteten.

For RISC Zero skriver utviklere Rust eller C++ (til slutt alt som er rettet mot RISC-V). Systemet tar deretter ELF-filen generert under kompilering og bruker den som inngangskode for VM-kretsen. Utviklere kaller ganske enkelt prove som returnerer en kvittering (som inneholder zk-beviset for utførelsessporet) som alle kan kalle 'verify' fra hvor som helst. Fra utviklerens synspunkt er det ikke nødvendig å forstå hvordan zk fungerer, det underliggende systemet håndterer all denne kompleksiteten.

For noen grunnleggende og gjenbrukbare kretser som er spesielt nyttige for blokkjedeapplikasjoner eller andre steder, kan team allerede ha bygget og optimalisert disse kretsene for deg. Du kan bare gi innspill for ditt spesielle bruksområde. Et Merkle-inkluderingsbevis er for eksempel noe som ofte er nødvendig i kryptoapplikasjoner (airdrop-lister, Tornado Cash, etc). Som applikasjonsutvikler kan du alltid gjenbruke disse kamptestede kontraktene og bare endre lagene på toppen for å lage en unik applikasjon.

For eksempel kan Tornado Cash sine kretser gjenbrukes for en privat airdrop-applikasjon eller en søknad om privat stemmegivning. Manta og Semaphore bygger et helt verktøysett med vanlige kretsutstyr som dette som kan brukes i Solidity-kontrakter med liten eller ingen forståelse av den underliggende zk moon-matematikken.

Som diskutert i lengden, er det en myriade av forskjellige alternativer for å utvikle en zk-applikasjon, alle med sitt eget unike sett med avveininger. Dette diagrammet vil hjelpe deg med å oppsummere denne beslutningsmatrisen slik at du kan velge det beste verktøyet for jobben basert på ditt nivå av zk-ekspertise og ytelsesbehov. Dette er ikke en uttømmende liste, jeg planlegger å legge til denne i fremtiden ettersom jeg blir oppmerksom på flere verktøy som kommer opp i rommet.

zk er i forkant av flere teknologier, og å bygge den krever en dyp forståelse av matematikk, kryptografi, informatikk og maskinvareteknikk. Likevel, med flere og flere abstraksjonslag tilgjengelig hver dag, kan apputviklere utnytte kraften til zk uten en Ph.D. Ettersom begrensningene for prøvetider sakte oppheves over tid via optimaliseringer på alle nivåer av stabelen, vil vi sannsynligvis se enda enklere verktøy for den gjennomsnittlige utvikleren.

Jeg håper jeg overbeviste deg, den nysgjerrige programvareutvikleren, om at du kan begynne å bruke zk i applikasjonene dine i dag. Lykke til med hacking 🙂

avsløringer: Blockchain Capital er en investor i flere av protokollene nevnt ovenfor.

Synspunktene uttrykt i hvert blogginnlegg kan være de personlige synspunktene til hver forfatter og reflekterer ikke nødvendigvis synspunktene til Blockchain Capital og dets tilknyttede selskaper. Verken Blockchain Capital eller forfatteren garanterer nøyaktigheten, tilstrekkeligheten eller fullstendigheten av informasjonen gitt i hvert blogginnlegg. Ingen representasjon eller garanti, uttrykt eller underforstått, er gitt eller gitt av eller på vegne av Blockchain Capital, forfatteren eller noen annen person med hensyn til nøyaktigheten og fullstendigheten eller rettferdigheten til informasjonen i et blogginnlegg, og intet ansvar eller ansvar aksepteres. for slik informasjon. Ingenting i hvert blogginnlegg utgjør investerings-, regulerings-, juridiske, overholdelses- eller skattemessige eller andre råd, og det er heller ikke til å stole på når du tar en investeringsbeslutning. Blogginnlegg skal ikke sees på som nåværende eller tidligere anbefalinger eller oppfordringer til et tilbud om å kjøpe eller selge verdipapirer eller å vedta noen investeringsstrategi. Blogginnleggene kan inneholde anslag eller andre fremtidsrettede utsagn, som er basert på tro, antagelser og forventninger som kan endre seg som følge av mange mulige hendelser eller faktorer. Hvis det skjer en endring, kan faktiske resultater avvike vesentlig fra de som er uttrykt i de fremtidsrettede uttalelsene. Alle fremtidsrettede utsagn taler kun fra datoen slike uttalelser er avgitt, og verken Blockchain Capital eller hver forfatter påtar seg noen plikt til å oppdatere slike uttalelser med unntak av det som kreves av loven. I den grad dokumenter, presentasjoner eller annet materiale produsert, publisert eller på annen måte distribuert av Blockchain Capital refereres til i et blogginnlegg, bør slikt materiale leses med nøye oppmerksomhet til eventuelle ansvarsfraskrivelser gitt deri.