Måling av SNARK-ytelse: Frontends, backends og fremtiden

En SNARK (Succinct Non-interactive Arguments of Knowledge) er et viktig kryptografisk primitivt funnprogram for skalerbarhet av blokkjeder (f.eks. L2-sammenrullinger) og personvern. SNARKs lar noen bevise for en upålitelig verifikator V (f.eks. Ethereum-blokkjeden) at de kjenner noen data (f.eks. en gruppe gyldige transaksjoner). En naiv måte å bevise dette på er å sende dataene til V, som deretter direkte kan kontrollere gyldigheten. En SNARK oppnår det samme, men med bedre kostnader til V. Spesielt bør et SNARK-bevis være kortere enn det naive beviset som omfatter selve dataene. (For mer detaljer, se utkastet til læreboken min, Bevis, argumenter og null kunnskap. For en introduksjon til SNARKs, se Sarah Meicklejohns presentasjon ved a16z-kryptoen Sommerforskningsserien.)

Verifikasjonskostnadene for SNARK-er kan variere, men er godt forstått og ofte ganske gode. For eksempel, PlonK bevis koster ca 290,000 gass å verifisere på Ethereum, mens StarkWare sine bevis koster rundt 5 millioner gass. SNARK-er er potensielt anvendelige i forskjellige omgivelser selv utenfor blokkjeder - for eksempel muliggjør bruk av raske, men upålitelige servere og maskinvare. 

Men fordi SNARK-verifisering vanligvis er billig, er hoveddeterminantene for anvendelighet kostnadene til SNARK-beviseren P. I dette innlegget forklarer jeg hvordan man estimerer disse kostnadene for å finne ut når det er rimelig å bruke SNARK-er, og hvordan SNARK-er kan bli bedre i fremtiden. Det er verdt å merke seg at dette er et raskt bevegelig rom, og flere av prosjektene som er omtalt i dette innlegget forbedrer aktivt ytelsen.

Men først: Hvordan SNARK-er distribueres

I SNARK-distribusjon skriver en utvikler vanligvis et dataprogram ψ som tar dataene som input w som beviseren hevder å vite (w står for Vitne), og sjekker det w er gyldig. For eksempel, i sammendrag, vil programmet sjekke at alle transaksjoner inn w er digitalt signert, ikke føre til at noen kontosaldo faller under null, og så videre. Programmet ψ blir deretter matet gjennom en SNARK frontend som kompilerer den til et format som er mer mottagelig for bruk av SNARK-teknologi. Dette SNARK-vennlige formatet kalles en mellomrepresentasjon (GÅ). 

Vanligvis er IR en slags kretstilfredshetsforekomst som tilsvarer ψ. Dette betyr at kretsen C tar dataene som input w, samt noen ekstra innganger som vanligvis kalles "ikke-deterministiske råd," og kjører ψ on w. Rådinngangene brukes til å hjelpe C løpe ψ, mens du holder C liten. For eksempel hver gang ψ deler to tall x og y, kvotienten q og resten r kan gis som råd til Cog C kan bare sjekke det x = qy + r. Denne sjekken er rimeligere enn å lage C kjøre en divisjonsalgoritme for å beregne q og r fra bunnen av.

Til slutt påføres en SNARK for krets-tilfredshet C. Dette kalles SNARK backend. For en håndfull svært strukturerte problemer som f.eks matrisemultiplikasjon, viklingerog flere grafiske problemer, finnes det kjente SNARK-er som unngår dette frontend/backend-paradigmet og dermed oppnår en mye raskere bevis. Men fokuset i dette innlegget er på generelle SNARK-er.

Som vi vil se, øker beviskostnadene til SNARK-backend med C's størrelse. Holde C liten kan være utfordrende, fordi kretser er et ekstremt begrenset format for å uttrykke en beregning. De består av porter, koblet av ledninger. Hver port g mates noen verdier og gjelder en veldig enkel funksjon til disse verdiene. Resultatet mates deretter inn i "nedstrøms" porter via ledningene som kommer fra g.

SNARK-skalerbarhet: Hvor mye tid tar det egentlig?

Nøkkelspørsmålet er, hvor mye mer tid tar SNARK-beviseren, i forhold til å bare gjenutføre ψ på dataene? Svaret er bevis overhead av SNARK, i forhold til direkte vitnekontroll. Det siste uttrykket refererer til det faktum at, i det naive beviset der P sender w til V, V sjekker wsin gyldighet ved å utføre ψ på den. 

Det er nyttig å dele opp testeren overhead i "frontend overhead" og "backend overhead." Hvis du evaluerer kretsen C gate-by-gate er F ganger dyrere enn å kjøre ψ, da sier vi at frontend overhead er F. Hvis du bruker backend-proveren på C is B ganger dyrere enn å vurdere C gate-by-gate, så sier vi at backend overhead er B. Den totale prover overhead er produkt, F·B. Denne multiplikasjonskostnaden kan være betydelig selv om F og B er individuelt beskjedne. 

I praksis, F og B kan begge være omtrent 1000 eller større. Dette betyr at den totale beviskostnaden i forhold til direkte vitnekontroll kan være 1 million til 10 millioner eller mer. Et program som kjører i bare ett sekund på en bærbar datamaskin, kan lett føre til at en SNARK-prøve krever titalls eller hundrevis av dager med beregningstid (en-trådet). Heldigvis er dette arbeidet typisk parallelliserbart i ulik grad (avhengig av SNARK). 

Oppsummert, hvis du vil bruke en SNARK i en applikasjon i dag, må en av tre ting være sanne:

1. Direkte vitnekontroll tar mye mindre enn ett sekund på en bærbar datamaskin.
2. Direkte vitnekontroll er spesielt mottakelig for representasjon i en krets, så frontend-overhead er liten.
3. Du er villig til å vente dager på at SNARK-beviseren er ferdig, og/eller betale for enorme parallelle dataressurser.

Tresten av dette innlegget forklarer hvor frontend og backend overhead kommer fra, og hvordan jeg estimerer dem for forskjellige SNARKs. Vi vil deretter gå til utsikter for forbedring. 

Skille frontends og backends

Å fullstendig skille frontends fra backends kan være utfordrende fordi forskjellige backends støtter forskjellige typer kretser. Derfor kan frontends variere avhengig av backend som de forventer å grensesnitt med.

SNARK-backends støtter generelt såkalte aritmetiske kretser, noe som betyr at inngangene til kretsene er elementer i et begrenset felt, og at portene til kretsen utfører addisjon og multiplikasjon av to feltelementer. Disse kretsene tilsvarer grovt sett lineære dataprogrammer (ingen grener, betingede utsagn og så videre) som er algebraiske i naturen - det vil si at deres primitive datatype er feltelementer. 

De fleste backends støtter faktisk en generalisering av aritmetiske kretser ofte kalt Rank-1 Constraint Satisfaction (R1CS)-instanser. Med det bemerkelsesverdige unntaket av Groth16 og dens forgjengere, disse SNARK-ene kan lages for å støtte andre IR-er også. For eksempel bruker StarkWare noe som kalles Algebraic Intermediate Representation (AIR), som også ligner på en forestilling som kalles PlonKish aritmetisering som kan støttes av PlonK og andre backends. Evnen til noen backends til å støtte mer generelle IR-er kan redusere overheaden til frontends som produserer disse IR-ene. 

Backends varierer også når det gjelder de endelige feltene som de naturlig støtter. Jeg vil diskutere dette videre i neste avsnitt.

Ulike tilnærminger til frontends

Noen (helt spesielle) dataprogrammer tilsvarer naturlig nok aritmetiske kretser. Et eksempel er dataprogrammet som utfører naiv multiplikasjon av matriser over et felt. Men de fleste dataprogrammer er verken rettlinjede eller algebraiske. De involverer ofte betingede utsagn, operasjoner som heltallsdivisjon eller flytekomma-aritmetikk som ikke naturlig tilsvarer finitt-felt-aritmetikk og mer. I disse tilfellene vil frontend-overhead være betydelig. 

En populær frontend-tilnærming er å produsere kretser som i hovedsak utfører trinn-for-trinn en enkel CPU, også kalt en virtuell maskin (VM). Frontend-designere spesifiserer et sett med "primitive operasjoner" analogt med monteringsinstruksjoner for ekte dataprosessorer. Utviklere som ønsker å bruke frontend, vil enten skrive "vitnekontrollprogrammer" direkte på assembly-språket eller ellers på et høyere nivåspråk som Solidity, og få programmene deres automatisk kompilert til assembly-kode. 

For eksempel StarkWares Kairo er et svært begrenset assemblerspråk der monteringsinstruksjoner grovt sett tillater addisjon og multiplikasjon over et begrenset felt, funksjonskaller og leser og skriver til et uforanderlig (dvs. skriv-en gang) minne. Cairo VM er en von Neumann-arkitektur, noe som betyr at kretsene produsert av frontend i hovedsak tar et Cairo-program som offentlig innspill og "kjører" programmet på vitnet. Kairo-språket er Turing Complete - til tross for det begrensede instruksjonssettet, kan det simulere flere standardarkitekturer, selv om det kan være dyrt å gjøre det. Kairo-grensesnittet gjør at Kairo-programmer kjøres T primitive instruksjoner til det som kalles en "grad-2 LUFT med T rader og om 50 kolonner." Hva akkurat dette betyr er ikke viktig for dette innlegget, men når det gjelder SNARK-provere, tilsvarer dette kretser med mellom 50 og 100 porter for hver av T trinnene til Cairo CPU. 

RISC null tar en lignende tilnærming til Kairo, men med den virtuelle maskinen som den såkalte RISC-V arkitektur, en åpen kildekode-arkitektur med et rikt programvareøkosystem som vokser i popularitet. Som et veldig enkelt instruksjonssett kan det være relativt håndterbart å designe en effektiv SNARK-frontend som støtter den (i det minste i forhold til kompliserte arkitekturer som x86 eller ARM). Fra mai, RISC Zero snur programmer utførende T primitive RISC-V-instruksjoner til grad-5 AIR-er med 3T rader og 160 kolonner. Dette tilsvarer kretser med minst 500 porter per trinn av RISC-V CPU. Ytterligere forbedringer er forventet i nær fremtid.

De forskjellige zkEVM-prosjektene (f.eks. zkSync 2.0, Scroll, Polygons zkEVM) tar den virtuelle maskinen til å være (duh) den virtuelle Ethereum-maskinen. Prosessen med å gjøre hver EVM-instruksjon om til en ekvivalent "gadget" (dvs. en optimalisert krets som implementerer instruksjonen) er vesentlig mer involvert enn for de enklere Cairo- og RISC-V-arkitekturene. Av denne og andre grunner, noen av zkEVM-prosjektene implementerer ikke EVM-instruksjonssettet direkte, men kompilerer heller høynivå-Solidity-programmer til andre assemblerspråk før de omdannes til kretser. Resultatresultater fra disse prosjektene venter.

"CPU-emulator"-prosjekter som RISC-V og Cairo produserer en enkelt krets som kan håndtere alle programmer i det tilhørende assemblerspråket. Alternative tilnærminger er "ASIC-lignende", som produserer forskjellige kretser for forskjellige programmer. Denne ASIC-lignende tilnærmingen kan gi mindre kretser for noen programmer, spesielt når monteringsinstruksjonen som programmet kjører ved hvert tidstrinn ikke er avhengig av programmets input. For eksempel kan det potensielt unngå frontend-overhead helt for rettlinjede programmer som naiv matrisemultiplikasjon. Men ASIC-tilnærmingen virker også svært begrenset; så vidt jeg vet, er det ikke kjent hvordan man bruker det til å støtte løkker uten forhåndsbestemte iterasjonsgrenser. 

Den siste komponenten av frontend-overhead kommer fra det faktum at alle SNARK-er bruker kretser som opererer over endelige felt. CPU-en på den bærbare datamaskinen kan multiplisere eller legge til to heltall med en enkelt maskininstruksjon. Hvis en frontend sender ut en krets over et felt med stor nok karakteristikk, kan den i hovedsak simulere den multiplikasjonen eller addisjonen via den tilsvarende feltoperasjonen. Imidlertid vil implementering av feltoperasjonen på en ekte CPU vanligvis kreve mange maskininstruksjoner (selv om noen moderne prosessorer har innebygd støtte for visse felt). 

Noen SNARK-backends muliggjør mer fleksible feltvalg enn andre. For eksempel hvis backend bruker en kryptografisk gruppe G, må kretsens felt samsvare med antall elementer i G, som kan være begrensende. I tillegg støtter ikke alle felt praktiske FFT-algoritmer. 

Det er bare en implementert SNARK, Bryte sammen, som naturlig støtter beregninger over vilkårlige (store nok) felt. Sammen med sin etterkommere, den har den raskeste kjente betongprøveytelsen selv over felt som andre SNARK-er støtter, men bevisene er foreløpig for store for mange blokkjedeapplikasjoner. Nylig arbeid søker å forbedre bevisstørrelsen, men beviset er asymptotisk langsommere og der ser ut til å være barrierer til det praktiske.

Noen prosjekter har valgt å arbeide over felt med spesielt rask regning. For eksempel, Plonky2 og andre bruker et felt med karakteristikk 2⁶⁴ - 2³² + 1 fordi aritmetikk i dette feltet kan implementeres flere ganger raskere enn i mindre strukturerte felt. Imidlertid kan bruk av en så liten karakteristikk føre til utfordringer med å effektivt representere heltallsaritmetikk via feltoperasjoner (f.eks. multiplisering av to 32-bits heltall uten fortegn kan gi et resultat som er større enn feltkarakteristikken). 

 Men uansett hva, for at alle populære SNARK-er i dag skal oppnå 128 bits sikkerhet (uten en betydelig økning i bekreftelseskostnader), må de jobbe over et felt som er større enn 2¹²⁸. Så vidt jeg kan si, betyr dette at hver feltoperasjon kommer til å kreve minst ti 64-bits maskinmultiplikasjoner, og betydelig flere addisjoner og bitvise operasjoner. Derfor bør man ta hensyn til minst en størrelsesorden frontend-overhead på grunn av behovet for kretser som opererer over endelige felt. 

For å oppsummere produserer eksisterende frontends som bruker en virtuell maskinabstraksjon kretser med 100x til 1000x porter per trinn på den virtuelle maskinen, og muligens mer for mer kompliserte virtuelle maskiner. På toppen av det, er finitt felt-aritmetikk minst 10 ganger tregere enn analoge instruksjoner på moderne prosessorer (med mulige unntak hvis prosessoren har innebygget støtte for enkelte felt). En "ASIC-frontend-tilnærming" kan redusere noen av disse omkostningene, men er foreløpig begrenset i hvilke typer programmer den kan støtte.

Hva er backend-flaskehalsene?

SNARK-er for krets-tilfredshet er vanligvis designet ved å kombinere en informasjonsteoretisk sikker protokoll kalt en "polynom IOP" med en kryptografisk protokoll kalt "polynomisk forpliktelsesordning." I de fleste tilfeller er den konkrete flaskehalsen for beviseren polynomforpliktelsesordningen. Spesielt har disse SNARK-ene at beviset kryptografisk forplikter seg til ett eller flere polynomer hvis grad er (minst) |C|, antall porter i kretsen C. 

I sin tur vil betongflaskehalsen innenfor polynomforpliktelsesordningen avhenge av ordningen som brukes og kretsstørrelsen. Men det vil alltid være en av følgende tre operasjoner: beregning av FFT-er, eksponentiasjoner i en kryptografisk gruppe, eller Merkle-hashing. Merkle-hashing er vanligvis en flaskehals bare hvis kretsen er liten, så vi vil ikke diskutere det videre. 

Polynomforpliktelser basert på diskret logg

I polynomiske forpliktelser basert på hardheten til det diskrete logaritmeproblemet i en kryptografisk gruppe G (KZG, Skuddsikker, Doryog Hyrax-forpliktelse), må beviseren beregne en Pedersen vektor engasjement til koeffisientene til polynomet. Dette innebærer en multi-eksponentiering, av størrelse lik polynomets grad. I SNARKs er denne graden vanligvis størrelsen |C| av kretsen C.

Gjort naivt, en multi-eksponentiering av størrelse |C| krever omtrent 1.5·|C|·logg |G| ≈ 400·|C| gruppedrift, hvor |G| angir antall elementer i gruppen G. Imidlertid er det en tilnærming, kalt Pippengers algoritme, som kan redusere dette med en faktor på omtrent log |C|. For store kretser (f.eks. |C| ≥ 225), denne loggen |C| faktor kan konkret være 25 eller mer, det vil si at for store kretser forventer vi at Pedersen vektorforpliktelsen kan beregnes med litt over 10·|C| gruppedrift. Hver gruppeoperasjon pleier i sin tur å være (som en veldig grov ballpark) omtrent 10 ganger langsommere enn en begrenset feltoperasjon. SNARKs som bruker disse polynomiske forpliktelsene er like dyre for P som rundt 100·|C| feltoperasjoner. 

Dessverre har eksisterende SNARK-er ekstra kostnader på toppen av 100x-faktoren ovenfor. For eksempel:

• Spartan's bevis, som bruker Hyrax polynomengasjement, må gjøre |C|^½ mange multi-eksponentiasjoner hver av størrelse |C|^½, noe som svekker hastigheten fra Pippengers algoritme med en faktor på omtrent to. 
• In Groth16, P må jobbe over en sammenkoblingsvennlig gruppe, hvis operasjoner vanligvis er minst 2 ganger langsommere enn grupper som ikke er sammenkoblingsvennlige. P må også utføre 3 multi-eksponentiseringer i stedet for 1. Kombinert resulterer dette i minst en ekstra faktor-6-reduksjon i forhold til 100·|C| estimat ovenfor. 
• Marlin og PlonK krever også sammenkoblinger, og deres beviser skal binde seg til betydelig mer enn 3 polynomer. 
• For enhver SNARK som bruker Skuddsikker (F.eks Halo2, som er omtrent PlonK, men med Bulletproofs i stedet for KZG polynomiske forpliktelser), må beviseren beregne logaritmisk mange multi-eksponentiasjoner i løpet av "åpningsfasen" av forpliktelsesskjemaet, og dette sletter i stor grad enhver Pippenger speedup. 

Oppsummert ser det ut til at kjente SNARK-er som bruker Pedersen vektorforpliktelser, har en backend-overhead på minst 200x og opptil 1000x eller mer. 

Andre polynomiske forpliktelser

For SNARK-er som bruker andre polynomiske forpliktelser (som f.eks Fredag og Ligero-forplikte), er flaskehalsen at beviseren må utføre store FFTs. For eksempel i grad-2 AIR-ene produsert av Kairo (med 51 kolonner og T rader, ett per trinn av Cairo CPU), StarkWares utplasserte tester gjør minst 2 FFT per kolonne, med lengde mellom 16 ·T og 32 ·T. Konstantene 16 og 32 avhenger av interne parametere til FRI som satt av StarkWare og kan reduseres - men på bekostning av økte verifikasjonskostnader. 

Optimistisk, en FFT med lengde 32·T tar ca 64·T·log(32T) feltmultiplikasjoner. Dette betyr at selv for relativt små verdier på T (F.eks T ≥ 2²⁰), antall feltoperasjoner per kolonne er minst 64·25·T= 1600·T. Så backend-overheaden ser ut til å være i det minste i tusenvis. Videre er det mulig at store FFT-er er enda mer flaskehalsede av minnebåndbredde enn av feltoperasjoner. 

I noen sammenhenger kan backend-overheaden til SNARK-er som utfører store FFT-er reduseres med en teknikk som kalles bevisaggregering. For rollups vil dette bety det P (sammendragstjenesten) deler opp en stor gruppe transaksjoner i for eksempel 10 mindre grupper. For hver liten batch i, P produserer et SNARK-bevis πi av partiets gyldighet. Men P legger ikke disse bevisene til Ethereum, da dette vil føre til en nesten 10-dobling av gasskostnadene. I stedet brukes SNARK igjen, denne gangen for å produsere et bevis π etablere det P vet π₁ ...,π₁₀. Altså vitnet som P hevder å vite er de ti bevisene π₁,…,π₁₀, og direkte vitnekontroll bruker SNARK-verifiseringsprosedyren på hvert av bevisene. Dette eneste beviset π er lagt til Ethereum. 

I polynomiske engasjementer som FRI og Ligero-commit er det en sterk spenning mellom P tid og V kostnader, med interne parametere som fungerer som en knott som kan bytte ut det ene for det andre. Siden π₁ ,…,π₁₀ ikke er lagt ut til Ethereum, kan knotten stilles inn slik at disse bevisene er store, og det går raskere å produsere dem. Bare i den endelige søknaden av SNARK, for å samle π₁ ,…,π₁₀ til et enkelt bevis π, må forpliktelsesordningen konfigureres for å sikre et lite bevis. 

StarkWare planlegger å distribuere bevisaggregering nært forestående. Dette er også fokus for prosjekter som f.eks Plonky2.

Hva er de andre flaskehalsene for SNARK-skalerbarhet?

Dette innlegget har fokusert på bevis tid, men andre beviskostnader kan også være skalerbarhetsflaskehalser. For eksempel, for mange SNARK-backends, trenger proveren å lagre flere feltelementer for hver gate i C, og denne plasskostnaden kan være enorm. For eksempel et program ψ kjører på ett sekund på en bærbar datamaskin kan utføre kanskje en milliard primitive operasjoner på en moderne prosessor. Som vi har sett, generelt bør man forvente C å kreve godt over 100 porter per slik operasjon. Dette betyr 100 milliarder porter, som, avhengig av SNARK, kan bety titalls eller hundrevis av terabyte plass for P. 

Et annet eksempel: mange populære SNARK-er (f.eks. PlonK, Marlin, Groth16) krever en komplisert «betrodd oppsettseremoni» for å generere en strukturert «bevisnøkkel» som må lagres av beviseren. Så vidt jeg vet, er største slik seremoni genererte en bevisnøkkel som er i stand til å støtte kretser med ca. 2²⁸≈250 millioner porter. Den bevisende nøkkelen er flere dusin gigabyte stor. 

I sammenhenger hvor bevisaggregering er mulig, kan disse flaskehalsene reduseres betydelig. 

Ser fremover: utsikter for mer skalerbare SNARK-er

Både frontend og backend overhead kan være tre størrelsesordener eller mer. Kan vi forvente at disse vil reduseres betydelig i nær fremtid? 

Jeg tror vi vil - til et punkt. For det første, de raskeste backends i dag (f.eks. Spartan og Bryte sammen, og andre SNARK-er som kombinerer sum-sjekk protokoll med polynomiske forpliktelser) har store bevis - vanligvis kvadratrot i størrelsen på kretsen - så folk bruker dem egentlig ikke. Jeg forventer at bevisstørrelsen og verifikatorens tid vil bli betydelig redusert i nær fremtid via dybde-en-komposisjon med småsikre SNARK-er. I likhet med bevisaggregering betyr dette at en beviser først vil generere et SNARK-bevis π med "hurtigbeviset, storsikret" SNARK, men ikke send π til V. Heller, P ville bruke en liten-proof SNARK for å produsere et bevis π' at den vet π, og send π' til V. Dette kan barbere en størrelsesorden ut av backend-overheadkostnadene til SNARK-er som er populære i dag. 

For det andre kan maskinvareakselerasjon hjelpe. En veldig grov generell regel er at GPUer kan kjøpe en 10x speedup over CPUer, og ASICer en 10x speedup over GPUer. Jeg har imidlertid tre bekymringer på denne fronten. For det første kan store FFT-er ha flaskehalser av minnebåndbredde i stedet for feltoperasjoner, så SNARK-er som utfører slike FFT-er kan se begrensede hastigheter fra spesialisert maskinvare. For det andre, mens dette innlegget fokuserte på flaskehalsen for polynomengasjement, krever mange SNARK-er at beviseren utfører andre operasjoner som bare er litt rimeligere. Så å bryte den polynomiske forpliktelsens flaskehals (f.eks. fremskynde multi-eksponentiseringer i diskrete loggbaserte SNARK-er) kan etterlate en ny flaskehalsoperasjon som ikke er mye bedre enn den gamle. (For eksempel har SNARK-er inkludert Groth16, Marlin og PlonK også FFT-er, i tillegg til multi-eksponentiasjoner.) Til slutt kan feltene og elliptiske kurvene som fører til de mest effektive SNARK-ene fortsette å utvikle seg en stund, og det kan skape utfordringer for ASIC-basert bevisakselerasjon.

På frontend-siden kan vi i økende grad finne at "CPU-emulator"-tilnærmingen til prosjekter som Cairo, RISC Zero, zkEVMs og andre faktisk skaleres ganske bra (i form av ytelse) med kompleksiteten til CPU-instruksjonssett. Dette er faktisk nettopp håpet til forskjellige zkEVM-prosjekter. Dette kan bety at mens frontend-overheaden forblir tre størrelsesordener eller mer, klarer frontends å støtte VM-er som i økende grad samsvarer med ekte CPU-arkitekturer. En motstridende bekymring er at grensesnittene kan bli kompliserte og vanskelige å revidere, ettersom håndkodede gadgets som implementerer stadig mer kompliserte instruksjoner sprer seg. Formelle verifiseringsmetoder vil sannsynligvis spille en viktig rolle for å løse denne bekymringen. 

Til slutt, i det minste i blokkjedeapplikasjoner, kan vi finne at de fleste smarte kontrakter som vises i naturen, primært bruker enkle, SNARK-vennlige instruksjoner. Dette kan muliggjøre lave grensesnittkostnader i praksis samtidig som man beholder generaliteten og den forbedrede utvikleropplevelsen som følger med å støtte programmeringsspråk på høyt nivå som Solidity og rike instruksjonssett, inkludert de til EVM. 

***

Justin Thaler is en førsteamanuensis ved Georgetown University. Før han begynte i Georgetown, tilbrakte han to år som forskningsforsker ved Yahoo Labs i New York, før han var stipendiat ved Simons Institute for theory of Computing ved UC Berkeley. 

***

Anerkjennelser: Jeg er takknemlig for Elena Burger for å foreslå emnet for dette innlegget, og til Arasu Arun, Joseph Bonneauog Sam Ragsdale for innsiktsfulle kommentarer. Spesiell takk også til redaktøren min, Tim Sullivan.

***

Synspunktene som uttrykkes her er de fra individuelle AH Capital Management, LLC (“a16z”) personell som er sitert og er ikke synspunktene til a16z eller dets tilknyttede selskaper. Visse opplysninger her er innhentet fra tredjepartskilder, inkludert fra porteføljeselskaper av fond forvaltet av a16z. Selv om a16z er hentet fra kilder som antas å være pålitelige, har ikke a16z uavhengig verifisert slik informasjon og gir ingen representasjoner om den varige nøyaktigheten til informasjonen eller dens hensiktsmessighet for en gitt situasjon. I tillegg kan dette innholdet inkludere tredjepartsannonser; aXNUMXz har ikke vurdert slike annonser og støtter ikke noe reklameinnhold som finnes deri.

Dette innholdet er kun gitt for informasjonsformål, og bør ikke stoles på som juridisk, forretningsmessig, investerings- eller skatterådgivning. Du bør rådføre deg med dine egne rådgivere om disse sakene. Referanser til verdipapirer eller digitale eiendeler er kun for illustrasjonsformål, og utgjør ikke en investeringsanbefaling eller tilbud om å tilby investeringsrådgivningstjenester. Videre er dette innholdet ikke rettet mot eller ment for bruk av noen investorer eller potensielle investorer, og kan ikke under noen omstendigheter stoles på når du tar en beslutning om å investere i et fond som forvaltes av a16z. (Et tilbud om å investere i et a16z-fond vil kun gis av det private emisjonsmemorandumet, tegningsavtalen og annen relevant dokumentasjon for et slikt fond og bør leses i sin helhet.) Eventuelle investeringer eller porteføljeselskaper nevnt, referert til, eller beskrevet er ikke representative for alle investeringer i kjøretøy forvaltet av a16z, og det kan ikke gis noen garanti for at investeringene vil være lønnsomme eller at andre investeringer som gjøres i fremtiden vil ha lignende egenskaper eller resultater. En liste over investeringer foretatt av fond forvaltet av Andreessen Horowitz (unntatt investeringer som utstederen ikke har gitt tillatelse til at a16z kan offentliggjøre så vel som uanmeldte investeringer i børsnoterte digitale eiendeler) er tilgjengelig på https://a16z.com/investments /.

Diagrammer og grafer gitt i er kun for informasjonsformål og bør ikke stoles på når du tar investeringsbeslutninger. Tidligere resultater er ikke en indikasjon på fremtidige resultater. Innholdet taler kun fra den angitte datoen. Eventuelle anslag, estimater, prognoser, mål, prospekter og/eller meninger uttrykt i dette materialet kan endres uten varsel og kan avvike eller være i strid med meninger uttrykt av andre. Vennligst se https://a16z.com/disclosures for ytterligere viktig informasjon.