En udviklervejledning til zkGalaxy

Dette er en yderst nyttig heuristik til at differentiere tilgange til at understøtte en zkEVM. Imidlertid er zkEVM'er en delmængde af alle de mulige måder at bygge nul vidensapplikationer på. For en programmør, der ønsker at udnytte de unikke egenskaber ved zk-beregning, nemlig kortfattethed, nul viden og korrekthed, er en zkEVM muligvis ikke det bedste valg. Ved at lægge hele sættet af udviklerværktøjer, håber jeg at give en guide, der hjælper i beslutningsprocessen omkring den rigtige zk-stack til din applikation.

I løbet af det seneste år eller to har der været en enorm fremgang inden for zk-værktøjer. De nærmer sig et punkt, hvor almindelige softwareudviklere kan udnytte de kraftfulde egenskaber ved zk uden en dyb forståelse af den skræmmende underliggende matematik og teknik. På den anden ende har der været en udbredelse af værktøjer til superbrugere, der giver zk-eksperter ekstremt fin kontrol over zk-stakken.

Moderne software er bygget på utallige lag af abstraktion for at maksimere specialistproduktiviteten. Der er mange fordele ved abstraktion i teknik, som er lidt intuitive – en webudvikler behøver ikke at forstå, hvordan operativsystemer fungerer i dybden. 

Nøglen til at bygge gode, genanvendelige abstraktionslag er at indkapsle kompleksiteten af ​​et lag og derefter give enkle, men alligevel udtryksfulde grænseflader til lag højere i stakken at bruge. Udført korrekt giver dette udviklere med forskellige ekspertise- og vidensområder mulighed for at bygge nyttige værktøjer på tværs af stakken.

Det er ikke overraskende, at de samme principper gælder for zk-systemer, og disse abstraktionslag er ved at blive modne nok til, at en zk-novice kan begynde at bruge dem og bygge applikationer i dag.

Arkværks-rs er et økosystem af Rust-biblioteker, der giver effektive og sikre implementeringer af underkomponenterne i en zkSNARK-applikation. Arkworks leverer de grænseflader, der er nødvendige for, at udviklere kan tilpasse softwarestakken til en zk-applikation uden at skulle genimplementere fællestræk med andre eksisterende biblioteker.

Før Arkworks var den eneste måde at oprette en ny zk-applikation på at bygge alt fra bunden. De vigtigste fordele ved Arkworks-rs i forhold til specialbyggede, vertikalt integrerede værktøjer er fleksibilitetsniveauet, reduktionen i duplikeret teknik og reduktionen i revisionsindsatsen. Arkworks' fornuftige grænsefladelinjer mellem komponenterne giver mulighed for et opgraderingstempo, der kan holde stakken relevant midt i det hæsblæsende innovationstempo inden for zk-teknologier, uden at tvinge teams til at genopbygge alt fra bunden.

Arkworks er til projekter, der har brug for fin kontrol over hele zk-softwarestakken, men ikke ønsker at bygge alle de overflødige stykker fra bunden. Hvis du overvejer en brugerdefineret version af et DSL-kredsløb, fordi du for eksempel laver prototyper til et nyt prøvesystem, men er usikker på forpligtelsesskemaet eller den tilsvarende elliptiske kurve, vil arkworks give dig mulighed for hurtigt at skifte mellem flere muligheder med delte grænseflader, snarere end at starte fra bunden.

For at skabe et bevis på en eller anden beregning, skal denne beregning først udtrykkes i en form, som et zkSNARK-system kan forstå. Adskillige domænespecifikke sprog har skabt programmeringssprog, der giver applikationsudviklere mulighed for at udtrykke deres beregninger på en sådan måde. Disse omfatter Aztec Noir, Starknets Cairo, Circom, ZoKrates, og Aleo's Leo blandt andre. Det underliggende bevissystem og matematiske detaljer er generelt ikke eksponeret for applikationsudvikleren.

zkApp-udviklere skal blive dygtige til at skrive deres programmer på domænespecifikke sprog. Nogle af disse sprog ligner meget velkendte programmeringssprog, mens andre kan være ret svære at lære. Lad os nedbryde et par af disse:

Cairo – Starkware DSL nødvendig for at bygge apps på Starknet. Kompilerer ned til Cairo-specifikt assemblersprog, der kan fortolkes af Cairo zkVM.

ZoKrates — ZoKrates er et værktøjssæt til almindelige SNARK-behov, herunder et sprog på højt niveau til at skrive kredsløb. ZoKrates har også en vis fleksibilitet omkring kurverne, bevisskemaet og backend, hvilket gør det muligt for udviklere at hot-swap med et simpelt CLI-argument.

Circom — Circom er et specialbygget sprog til at konstruere kredsløb. I øjeblikket er det de-facto sprog for kredsløb i produktion. Sproget er ikke specielt ergonomisk. Sproget i sig selv gør dig meget opmærksom på, at du skriver kredsløb.

Leo - Leo blev udviklet som sproget for Aleo blockchain. Leo har noget Rust-lignende syntaks og er specielt lavet til tilstandsovergange inde i en blockchain.

Noir – Rustinspireret syntaks. Arkitekteret omkring IR snarere end sproget selv, hvilket betyder, at det kan have en vilkårlig frontend. 

Enhver applikationsudvikler, der ønsker at drage fordel af de unikke egenskaber ved zk i deres applikation. Nogle af disse sprog er blevet kamptestet med milliarder af dollars, der bevæger sig på tværs af dem via kæder som ZCash og Starknet. Selvom nogle af de projekter, vi vil diskutere, ikke er helt klar til produktionsbrug, er det i øjeblikket den bedste strategi at skrive dine kredsløb på et af disse sprog, medmindre du har brug for de finere kontroller, som et værktøjssæt som Arkworks giver.

Det primære mål med en zkEVM er at tage en Ethereum-tilstandsovergang og bevise dens gyldighed ved hjælp af et kortfattet nul-vidensbevis for korrekthed. Som nævnt i Vitaliks indlæg er der en række måder at gøre dette på med subtile forskelle og tilsvarende afvejninger. 

Den væsentligste tekniske forskel mellem alle disse er præcis, hvor i sprogstakken beregningen konverteres til en form (aritmetisering), der kan bruges i et bevissystem. I nogle zkEVM'er sker dette på højniveausprogene (Solidity, Vyper, Yul), mens andre tilgange forsøger at bevise EVM'en helt til opkodeniveauet. Afvejningen mellem disse tilgange blev dækket dybt i Vitaliks indlæg, men jeg vil opsummere det i én sætning: Jo lavere konverteringen/aritmetiseringen sker i stakken, jo større bliver præstationsstraffen.

Den største udfordring med at skabe beviser til en virtuel maskine er, at størrelsen af ​​kredsløbet vokser proportionalt med størrelsen af ​​ALLE mulige instruktioner for hver udført instruktion. Dette sker, fordi kredsløbet ikke ved, hvilke instruktioner der vil blive udført i hvert program, så det skal understøtte dem alle.

Det betyder i praksis, at du betaler (i præstationsomkostning) for den dyrest mulige instruktion, selv når du kun udfører den enkleste instruktion. Dette fører til en direkte afvejning mellem generaliserbarhed og ydeevne – efterhånden som du tilføjer flere instruktioner til generaliserbarhed, betaler du for dette på hver instruktion du beviser!

Dette er et grundlæggende problem med universelle kredsløb, men med nye teknologiske udviklinger ligesom IVC (incremental verificable compute), kan denne begrænsning forbedres ved at opdele beregningen i mindre bidder, som hver har specialiserede, mindre underkredsløb.

Dagens zkEVM-implementeringer bruger forskellige strategier til at afbøde virkningen af ​​dette problem... For eksempel river zkSync de dyrere operationer ud (for det meste kryptografiske præ-kompileringer som hashes og ECDSA) fra det primære udførelsesbevisende kredsløb til separate kredsløb, der er aggregeret sammen på ende via snark rekursion. zkSync tog denne tilgang, efter at de indså, at størstedelen af ​​deres omkostninger kom fra nogle få komplekse instruktioner.

Grunden til, at det er dyrere at bevise et mere EVM-ækvivalent instruktionssæt, er, at EVM ikke er designet til zk-beregninger. At opgive EVM tidligere i stakken giver zkEVM'er mulighed for at køre på instruktionssæt, der er mere optimeret til zk og dermed billigere at bevise.

De ideelle kunder til en zkEVM er smarte kontraktapplikationer, der har brug for størrelsesordener billigere transaktioner end hvad der er tilgængeligt på L1 Ethereum. Disse udviklere har ikke nødvendigvis ekspertisen eller båndbredden til at skrive zk-applikationer fra bunden. Derfor foretrækker de at skrive deres ansøgninger på overordnede sprog, de er fortrolige med, såsom Solidity. 

Skalering af Ethereum er i øjeblikket den mest efterspurgte anvendelse af zk-teknologi.

En zkEVM er en Ethereum-skaleringsløsning, der friktionsfrit afhjælper overbelastningsproblemet, der begrænser L1 dApp-udviklere.

Målet med en zkEVM er at understøtte en udvikleroplevelse, der er så tæt som muligt på den nuværende Ethereum-udvikling. Fuld Solidity-understøttelse betyder, at teams ikke behøver at bygge og vedligeholde flere kodebaser. Dette er noget upraktisk at gøre perfekt, fordi zkEVM'er skal afveje en vis kompatibilitet for at kunne generere beviser af rimelig størrelse inden for en rimelig tid.

Den primære forskel mellem zkSync og Scroll er hvor/hvornår i stakken de udfører aritmetisering – altså hvor de konverterer fra normale EVM-konstruktioner til en SNARK-venlig repræsentation. For zkSync sker dette, når de konverterer YUL-bytekoden til deres eget brugerdefinerede zk-instruktionssæt. For Scroll sker dette i slutningen, når den faktiske udførelsessporing genereres med faktiske EVM-opkoder.

Så for zkSync er alt det samme som at interagere med EVM, indtil zk-bytekoden er genereret. For Scroll er alt det samme, indtil den faktiske bytekode udføres. Dette er en subtil forskel, som udligner ydeevne for støtte. For eksempel vil zkSync ikke understøtte EVM bytecode værktøjer som en debugger ud af boksen, fordi det er en helt anden bytekode. Mens Scroll vil have sværere ved at få god ydeevne ud af et instruktionssæt, var det ikke designet til zk. Der er fordele og ulemper ved begge strategier, og i sidste ende er der en masse eksogene faktorer, der vil påvirke deres relative succes.

💡 På trods af dens navngivning er LLVM ikke en VM (virtuel maskine). LLVM er navnet på et sæt kompileringsværktøjer, der er forankret af en mellemrepræsentation (IR), der er sprogagnostisk.

=nul; Foundation (om navnet, det er en SQL-injektion joke hvis du undrer dig) bygger en compiler, der kan konvertere ethvert LLVM-frontend-sprog til en mellemrepræsentation, der kan bevises i en SNARK. zkLLVM er bygget som en udvidelse til den eksisterende LLVM-infrastruktur, en industristandard værktøjskæde, der understøtter mange højniveausprog som Rust, C, C++ osv.

En bruger, der ønsker at bevise en eller anden beregning, ville simpelthen implementere denne beregning i C++. zkLLVM tager denne kildekode på højt niveau, der understøttes af deres modificerede clang-kompiler (i øjeblikket C++) og genererer en mellemliggende repræsentation af kredsløbet. På dette tidspunkt er kredsløbet klar til at blive bevist, men brugeren ønsker måske at bevise kredsløbet baseret på nogle dynamiske input. For at håndtere dynamiske input har zkLLVM en ekstra komponent kaldet tildeleren, som genererer en tildelingstabel med alle input og vidner fuldt forbehandlet og klar til at blive bevist sammen med kredsløbet.

Disse 2 komponenter er alt, hvad der er nødvendigt for at generere et bevis. En bruger kan teoretisk generere et bevis selv, men da dette er en noget specialiseret beregningsopgave, vil de måske betale en anden, som har hardwaren, for at gøre det for dem. For denne modparts opdagelsesmekanisme, =nul; Foundation har også etableret et 'bevismarked', hvor bevisere kappes om at bevise beregninger for brugere, der vil betale dem for at gøre det. Denne frie markedsdynamik vil føre til, at bevisere optimerer de mest værdifulde bevisopgaver.

Da hver beregningsopgave, der skal bevises, er unik og genererer et andet kredsløb, er der et uendeligt antal kredsløb, som beviserne skal kunne håndtere. Denne tvungne generaliserbarhed gør optimering af individuelle kredsløb vanskelig. Indførelsen af ​​et bevismarked tillader specialisering på de kredsløb, som markedet anser for værdifulde. Uden dette marked ville det være udfordrende at overbevise en tester om at optimere dette kredsløb på grund af dette naturlige koldstartproblem.

Den anden afvejning er den klassiske abstraktion vs. kontrol. Brugere, der er villige til at tage denne brugervenlige grænseflade, opgiver kontrollen over de underliggende kryptografiske primitiver. For mange brugere er dette en meget gyldig afvejning, da det ofte er bedre at lade kryptografieksperterne tage disse beslutninger for dig.

En zkVM beskriver supersættet af alle zk virtuelle maskiner, mens en zkEVM er en specifik type zkVM, som var værd at diskutere som et separat emne på grund af dets udbredelse i dag. Der er et par andre projekter, der arbejder på at bygge mere generaliserede zkVM'er, der er baseret på ISA'er udover de skræddersyede krypto-VM'er.

I stedet for at bevise EVM'en kunne systemet bevise en anden instruktionssætarkitektur (ISA), såsom RISC-V eller WASM i en ny VM. To projekter, der arbejder på disse generaliserede zkVM'er, er RISC Zero og zkWASM. Lad os dykke lidt ned i RISC Zero her for at demonstrere, hvordan denne strategi fungerer og nogle af dens fordele/ulemper. 

RISC Zero er i stand til at bevise enhver beregning, der udføres på en RISC-V-arkitektur. RISC-V er en open source-standard for instruktionssætarkitektur (ISA), som er blevet mere populær. RISC-filosofien (reduced instruction set computer) er at bygge et ekstremt simpelt instruktionssæt med minimal kompleksitet. Det betyder, at udviklerne på de højere lag i stakken ender med at påtage sig en større belastning med at implementere instruktioner ved hjælp af denne arkitektur og samtidig gøre hardwareimplementeringen enklere.

Denne filosofi gælder også for generel databehandling, ARM-chips har udnyttet RISC-stil instruktionssæt og er begyndt at dominere markedet for mobile chips. Det viser sig, at de mere simple instruktionssæt også har større energi- og matriceeffektivitet.

Denne analogi holder ret godt for effektiviteten af ​​at generere zk-beviser. Som nævnt tidligere, når du beviser et udførelsesspor i zk, betaler du for summen af ​​omkostningerne for alle instruktioner pr. hvert element i sporet, så enklere og færre samlede instruktioner er bedre.

Fra et udviklerperspektiv er brug af RISC Zero til at håndtere zk-beviser meget som at bruge AWS Lambda-funktioner til at håndtere backend-serverarkitektur. Udviklere interagerer med RISC Zero eller AWS Lambda ved blot at skrive kode, og tjenesten håndterer al backend-kompleksiteten.

For RISC Zero skriver udviklere Rust eller C++ (efterhånden alt, der er rettet mod RISC-V). Systemet tager derefter ELF-filen, der blev genereret under kompileringen, og bruger den som inputkode for VM-kredsløbet. Udviklere kalder simpelthen bevis, som returnerer en kvittering (som indeholder zk-beviset for eksekveringssporet), som enhver kan kalde 'verify' fra hvor som helst. Fra udviklerens synspunkt er der ingen grund til at forstå, hvordan zk fungerer, det underliggende system håndterer al denne kompleksitet.

For nogle grundlæggende og genbrugelige kredsløb, der er særligt nyttige til blockchain-applikationer eller andre steder, kan teams allerede have bygget og optimeret disse kredsløb for dig. Du kan bare give input til din særlige brugssag. Et Merkle-inkluderingsbevis er for eksempel noget, der almindeligvis er nødvendigt i kryptoapplikationer (airdrop-lister, Tornado Cash osv.). Som applikationsudvikler kan du altid genbruge disse kamptestede kontrakter og bare ændre lagene på toppen for at skabe en unik applikation.

For eksempel kan Tornado Cashs kredsløb genbruges til en privat airdrop-applikation eller privat stemmeansøgning. Manta og Semaphore bygger et helt værktøjssæt af almindelige kredsløbsgadgets som dette, der kan bruges i Solidity-kontrakter med ringe eller ingen forståelse af den underliggende zk moon matematik.

Som diskuteret indgående, er der et utal af forskellige muligheder for at udvikle en zk-applikation, alle med deres eget unikke sæt af afvejninger. Dette diagram hjælper med at opsummere denne beslutningsmatrix, så du kan vælge det bedste værktøj til jobbet baseret på dit niveau af zk-ekspertise og præstationsbehov. Dette er ikke en udtømmende liste, jeg planlægger at tilføje til denne i fremtiden, efterhånden som jeg bliver opmærksom på flere værktøjer, der kommer op i rummet.

zk er på forkant med flere teknologier, og opbygningen af ​​det kræver en dyb forståelse af matematik, kryptografi, datalogi og hardwareteknik. Men med flere og flere abstraktionslag tilgængelige hver dag, kan appudviklere udnytte kraften i zk uden en Ph.D. Da begrænsningerne af bevistider langsomt løftes over tid via optimeringer på alle niveauer af stakken, vil vi sandsynligvis se endnu enklere værktøjer for den gennemsnitlige udvikler.

Jeg håber, jeg har overbevist dig, den nysgerrige softwareudvikler, om, at du kan begynde at bruge zk i dine applikationer i dag. Godt hacking 🙂

Oplysninger: Blockchain Capital er investor i flere af ovennævnte protokoller.

Synspunkterne i hvert blogindlæg kan være den enkelte forfatters personlige synspunkter og afspejler ikke nødvendigvis synspunkterne fra Blockchain Capital og dets tilknyttede selskaber. Hverken Blockchain Capital eller forfatteren garanterer nøjagtigheden, tilstrækkeligheden eller fuldstændigheden af ​​oplysningerne i hvert blogindlæg. Ingen repræsentation eller garanti, hverken udtrykkelig eller underforstået, er givet eller givet af eller på vegne af Blockchain Capital, forfatteren eller nogen anden person med hensyn til nøjagtigheden og fuldstændigheden eller retfærdigheden af ​​oplysningerne indeholdt i et blogindlæg, og intet ansvar eller ansvar accepteres. for sådanne oplysninger. Intet indeholdt i hvert blogindlæg udgør investerings-, lovgivnings-, lov-, overholdelses- eller skatte- eller anden rådgivning, og det er heller ikke til at stole på, når der skal træffes en investeringsbeslutning. Blogindlæg bør ikke ses som aktuelle eller tidligere anbefalinger eller opfordringer til et tilbud om at købe eller sælge værdipapirer eller vedtage en investeringsstrategi. Blogindlæggene kan indeholde fremskrivninger eller andre fremadrettede udsagn, som er baseret på overbevisninger, antagelser og forventninger, der kan ændre sig som følge af mange mulige begivenheder eller faktorer. Hvis der sker en ændring, kan de faktiske resultater afvige væsentligt fra dem, der er udtrykt i de fremadrettede udsagn. Alle fremadrettede udsagn taler kun fra datoen for sådanne udsagn, og hverken Blockchain Capital eller hver forfatter påtager sig nogen pligt til at opdatere sådanne udsagn, undtagen som krævet ved lov. I det omfang der henvises til dokumenter, præsentationer eller andet materiale, der er produceret, offentliggjort eller på anden måde distribueret af Blockchain Capital, i et blogindlæg, skal sådanne materialer læses med omhyggelig opmærksomhed på eventuelle ansvarsfraskrivelser deri.