Måling af SNARK-ydeevne: Frontends, backends og fremtiden

En SNARK (Succinct Non-interactive Arguments of Knowledge) er en vigtig kryptografisk primitiv findeapplikation til blockchain-skalerbarhed (f.eks. L2-oprulninger) og privatliv. SNARKs lader nogen bevise for en tillidsfuld verifikator V (f.eks. Ethereum blockchain), at de kender nogle data (f.eks. en batch af gyldige transaktioner). En naiv måde at bevise dette på ville være at sende dataene til V, som så direkte kan kontrollere dens gyldighed. En SNARK opnår det samme, men med bedre omkostninger til V. Især bør et SNARK-bevis være kortere end det naive bevis, der omfatter selve dataene. (For flere detaljer, se udkastet til min lærebog, Beviser, argumenter og nul viden. For en introduktion til SNARKs, se Sarah Meicklejohns præsentation ved a16z-kryptoen Sommerforskningsserie.)

Verifikationsomkostningerne for SNARK'er kan variere, men er velforståede og ofte ret gode. For eksempel, PlonK beviser koster ca 290,000 gas at verificere på Ethereum, mens StarkWares beviser koster omkring 5 millioner gas. SNARK'er er potentielt anvendelige i forskellige omgivelser selv uden for blockchains - for eksempel muliggør brugen af ​​hurtige, men upålidelige servere , hardware. 

Men fordi SNARK-verifikation typisk er billig, er de vigtigste determinanter for anvendelighed omkostningerne ved SNARK-beviseren P. I dette indlæg forklarer jeg, hvordan man estimerer disse omkostninger for at bestemme, hvornår det er rimeligt at bruge SNARK'er, og hvordan SNARK'er kan forbedres i fremtiden. Det er værd at bemærke, at dette er et hurtigt bevægende rum, og flere af de projekter, der diskuteres i dette indlæg, forbedrer aktivt deres ydeevne.

Men først: Hvordan SNARK'er indsættes

I SNARK-implementering skriver en udvikler typisk et computerprogram ψ der tager dataene som input w som beviseren hævder at vide (w står for vidne), og tjekker det w er gyldig. For eksempel vil programmet i rollups kontrollere, at alle transaktioner i w er digitalt signeret, får ikke nogen kontosaldi til at falde til under nul, og så videre. Programmet ψ bliver derefter fodret gennem en SNARK frontend der kompilerer det til et format, der er mere egnet til anvendelse af SNARK-teknologi. Dette SNARK-venlige format kaldes et mellemrepræsentation (IR). 

Typisk er IR en slags kredsløbstilfredsstillelsesinstans, der svarer til ψ. Det betyder, at kredsløbet C tager dataene som input w, samt nogle ekstra input, der typisk kaldes "ikke-deterministisk rådgivning", og kører ψ on w. Rådgivningens input bruges til at hjælpe C køre ψ, mens du holder C lille. For eksempel hver gang ψ deler to tal x , y, kvotienten q og resten r kan gives som rådgivning til Cog C kan bare tjekke det x = qy + r. Denne check er billigere end at lave C køre en divisionsalgoritme til at beregne q , r fra bunden.

Til sidst anvendes en SNARK for kredsløbstilfredsstillelse C. Dette kaldes SNARK backend. Til en håndfuld meget strukturerede problemer som f.eks matrix multiplikation, viklingerog flere grafiske problemer, findes der kendte SNARK'er, der undgår dette frontend/backend-paradigme og derved opnår en langt hurtigere bevis. Men fokus i dette indlæg er på SNARK'er til generelle formål.

Som vi vil se, vokser prover-omkostningerne ved SNARK-backend med C's størrelse. Beholde C small kan være udfordrende, fordi kredsløb er et ekstremt begrænset format til at udtrykke en beregning. De består af porte, tilsluttet af ledninger. Hver port g er fodret med nogle værdier og anvender en meget enkel funktion til disse værdier. Resultatet føres derefter ind i "nedstrøms" porte via ledningerne, der udgår fra g.

SNARK-skalerbarhed: Hvor meget tid tager det egentlig?

Nøglespørgsmålet er, hvor meget mere tid tager SNARK-beviseren i forhold til blot at genudføre ψ på data? Svaret er bevis overhead af SNARK, ift direkte vidnekontrol. Sidstnævnte udtryk henviser til, at i det naive bevis, hvori P sender w til V, V kontrol w's gyldighed ved at udføre ψ på det. 

Det er nyttigt at opdele testeren overhead i "frontend overhead" og "backend overhead." Hvis man vurderer kredsløbet C port-by-gate er F gange dyrere end at køre ψ, så siger vi, at frontend overhead er F. Hvis du anvender backend-beviseren til C is B gange dyrere end at vurdere C gate-by-gate, så siger vi, at backend overhead er B. Den samlede prover overhead er produkt, F·B. Denne multiplikative overhead kan være betydelig, selvom F , B er individuelt beskedne. 

I praksis, F , B kan begge være omkring 1000 eller større. Dette betyder, at de samlede bevisomkostninger i forhold til direkte vidnekontrol kan være 1 million til 10 millioner eller mere. Et program, der kører i kun et sekund på en bærbar computer, kan nemt føre til, at en SNARK-beviser kræver ti eller hundreder af dages beregningstid (entrådet). Heldigvis er dette arbejde typisk paralleliserbart i varierende omfang (afhængigt af SNARK). 

Sammenfattende, hvis du vil bruge en SNARK i en applikation i dag, så skal en af ​​tre ting være sande:

1. Direkte vidnekontrol tager meget mindre end et sekund på en bærbar computer.
2. Direkte vidnekontrol er særligt modtagelig for repræsentation i et kredsløb, så frontend-overhead er lille.
3. Du er villig til at vente dage på, at SNARK-proveren er færdig, og/eller betale for enorme parallelle computerressourcer.

Tresten af ​​dette indlæg forklarer, hvor frontend- og backend-overheads kommer fra, og hvordan jeg estimerer dem for forskellige SNARK'er. Vi vil derefter vende os til udsigter til forbedring. 

Adskillelse af frontends og backends

Det kan være en udfordring at adskille frontends fra backends fuldstændigt, fordi forskellige backends understøtter forskellige slags kredsløb. Derfor kan frontends variere afhængigt af den backend, som de forventer at interface med.

SNARK-backends understøtter generelt såkaldte aritmetiske kredsløb, hvilket betyder, at input til kredsløbene er elementer i et eller andet endeligt felt, og at kredsløbets porte udfører addition og multiplikation af to feltelementer. Disse kredsløb svarer nogenlunde til lineære computerprogrammer (ingen forgreninger, betingede udsagn og så videre), der er algebraiske i naturen - det vil sige, at deres primitive datatype er feltelementer. 

De fleste backends understøtter faktisk en generalisering af aritmetiske kredsløb, ofte kaldet Rank-1 Constraint Satisfaction (R1CS) instanser. Med den bemærkelsesværdige undtagelse af Groth16 og dets forgængere kan disse SNARK'er også laves til at understøtte andre IR'er. For eksempel bruger StarkWare noget, der hedder Algebraic Intermediate Representation (AIR), som også ligner en forestilling, der hedder PlonKish aritmetisering der kan understøttes af PlonK og andre backends. Muligheden for nogle backends til at understøtte mere generelle IR'er kan reducere omkostningerne ved frontends, der producerer disse IR'er. 

Backends varierer også med hensyn til de begrænsede felter, som de naturligt understøtter. Jeg vil diskutere dette yderligere i næste afsnit.

Forskellige tilgange til frontends

Nogle (helt specielle) computerprogrammer svarer naturligvis til aritmetiske kredsløb. Et eksempel er computerprogrammet, der udfører naiv multiplikation af matricer over et eller andet felt. Men de fleste computerprogrammer er hverken lineære eller algebraiske. De involverer ofte betingede udsagn, operationer såsom heltalsdivision eller flydende komma-aritmetik, der ikke naturligt svarer til finite field-aritmetik og mere. I disse tilfælde vil frontend-overhead være betydelig. 

En populær frontend-tilgang er at producere kredsløb, der i det væsentlige udfører trin-for-trin en simpel CPU, også kaldet en virtuel maskine (VM). Frontend-designere specificerer et sæt "primitive operationer" analogt med monteringsinstruktioner for rigtige computerprocessorer. Udviklere, der ønsker at bruge frontend, vil enten skrive "vidnekontrolprogrammer" direkte i assemblersproget eller ellers i et sprog på et højere niveau, såsom Solidity, og få deres programmer automatisk kompileret til assemblerkode. 

For eksempel StarkWare's Cairo er et meget begrænset assemblersprog, hvor assemblerinstruktioner groft tillader addition og multiplikation over et endeligt felt, funktionskald og læser og skriver til en uforanderlig (dvs. skrive-en gang) hukommelse. Cairo VM er en von Neumann-arkitektur, hvilket betyder, at de kredsløb, der produceres af frontenden, i det væsentlige tager et Cairo-program som offentligt input og "kører" programmet på vidnet. Cairo-sproget er Turing Complete - på trods af dets begrænsede instruktionssæt, kan det simulere flere standardarkitekturer, selvom det kan være dyrt at gøre det. Cairo-frontenden gør Cairo-programmer kørende T primitive instruktioner til det, der kaldes en "grad-2 LUFT med T rækker og omkring 50 kolonner." Hvad præcis dette betyder er ikke vigtigt for dette indlæg, men hvad angår SNARK-provere, svarer dette til kredsløb med mellem 50 og 100 porte for hver af de T trin af Cairo CPU. 

RISC nul tager en lignende tilgang til Kairo, men med den virtuelle maskine som den såkaldte RISC-V arkitektur, en open source-arkitektur med et rigt software-økosystem, der vokser i popularitet. Som et meget simpelt instruktionssæt kan det være relativt håndterbart at designe en effektiv SNARK-frontend, der understøtter den (i det mindste i forhold til komplicerede arkitekturer såsom x86 eller ARM). Fra maj, RISC Zero drejer programmer udførelse T primitive RISC-V instruktioner til grad-5 AIRs med 3T rækker og 160 kolonner. Dette svarer til kredsløb med mindst 500 porte pr. trin af RISC-V CPU'en. Yderligere forbedringer forventes i den nærmeste fremtid.

De forskellige zkEVM-projekter (f.eks. zkSync 2.0, Scroll, Polygons zkEVM) tager den virtuelle maskine til at være (duh) Ethereum Virtual Machine. Processen med at omdanne hver EVM-instruktion til en tilsvarende "gadget" (dvs. et optimeret kredsløb, der implementerer instruktionen) er væsentligt mere involveret end for de mere simple Cairo- og RISC-V-arkitekturer. Af denne og andre grunde, nogle af zkEVM-projekterne implementerer ikke direkte EVM-instruktionssættet, men kompilerer snarere højniveau Solidity-programmer til andre assemblersprog, før de omdannes til kredsløb. Præstationsresultater fra disse projekter afventer.

"CPU emulator" projekter som RISC-V og Cairo producerer et enkelt kredsløb, der kan håndtere alle programmer i det tilhørende assemblersprog. Alternative tilgange er "ASIC-lignende", der producerer forskellige kredsløb til forskellige programmer. Denne ASIC-lignende tilgang kan give mindre kredsløb for nogle programmer, især når monteringsinstruktionen, som programmet udfører på hvert tidstrin, ikke afhænger af programmets input. For eksempel kan det potentielt undgå frontend-overhead helt for lineære programmer såsom naiv matrixmultiplikation. Men ASIC-tilgangen virker også meget begrænset; så vidt jeg ved, er det ikke kendt, hvordan man bruger det til at understøtte loops uden forudbestemte iterationsgrænser. 

Den sidste komponent i frontend-overhead kommer fra det faktum, at alle SNARK'er bruger kredsløb, der opererer over begrænsede felter. CPU'en på din bærbare computer kan multiplicere eller tilføje to heltal med en enkelt maskininstruktion. Hvis en frontend udsender et kredsløb over et felt med stor nok karakteristik, kan den i det væsentlige simulere denne multiplikation eller addition via den tilsvarende feltoperation. Imidlertid vil implementering af feltoperationen på en rigtig CPU typisk kræve mange maskininstruktioner (selvom nogle moderne processorer har indbygget understøttelse af visse felter). 

Nogle SNARK-backends muliggør mere fleksible feltvalg end andre. For eksempel hvis backend gør brug af en kryptografisk gruppe G, skal kredsløbets felt matche antallet af elementer i G, hvilket kan være begrænsende. Derudover understøtter ikke alle felter praktiske FFT-algoritmer. 

Der er kun én implementeret SNARK, Nedbremsning, der naturligt understøtter beregninger over vilkårlige (store nok) felter. Sammen med sin efterkommere, den har den hurtigste kendte konkrete bevisydelse, selv over felter, som andre SNARK'er understøtter, men dens beviser er i øjeblikket for store til mange blockchain-applikationer. Seneste arbejde søger at forbedre bevisstørrelsen, men beviseren er asymptotisk langsommere og der synes at være barrierer til det praktiske.

Nogle projekter har valgt at arbejde over felter med særlig hurtig regning. For eksempel, Plonky2 og andre bruger et felt med karakteristik 2⁶⁴ - 2³² + 1 fordi aritmetik i dette felt kan implementeres flere gange hurtigere end i mindre strukturerede felter. Brug af en så lille karakteristik kan imidlertid føre til udfordringer med effektivt at repræsentere heltalsaritmetik via feltoperationer (f.eks. kan multiplicering af to 32-bit heltal uden fortegn give et resultat, der er større end feltkarakteristikken). 

 Men uanset hvad, for at alle populære SNARK'er i dag skal opnå 128 bits sikkerhed (uden en væsentlig stigning i verifikationsomkostninger), skal de arbejde over et felt med størrelse større end 2¹²⁸. Så vidt jeg kan se, betyder det, at hver feltoperation vil kræve mindst omkring ti 64-bit maskinmultiplikationer og betydeligt flere additioner og bitvise operationer. Derfor bør man medregne mindst en størrelsesorden frontend-overhead på grund af behovet for kredsløb, der opererer over begrænsede felter. 

For at opsummere, producerer eksisterende frontends, der bruger en virtuel maskineabstraktion, kredsløb med 100x til 1000x porte pr. trin på den virtuelle maskine, og muligvis mere til mere komplicerede virtuelle maskiner. Oven i det er finite field aritmetik mindst 10 gange langsommere end analoge instruktioner på moderne processorer (med mulige undtagelser, hvis processoren har indbygget understøttelse af visse felter). En "ASIC frontend-tilgang" kan reducere nogle af disse overheadomkostninger, men er i øjeblikket begrænset i den slags programmer, den kan understøtte.

Hvad er flaskehalse i backend?

SNARK'er til kredsløbstilfredshed er typisk designet ved at kombinere en informationsteoretisk sikker protokol kaldet en "polynomisk IOP" med en kryptografisk protokol kaldet en "polynomisk forpligtelsesordning." I de fleste tilfælde er den konkrete flaskehals for beviseren den polynomielle forpligtelsesordning. Især har disse SNARK'er beviseren kryptografisk forpligtet til et eller flere polynomier, hvis grad er (mindst) |C|, antallet af porte i kredsløbet C. 

Til gengæld vil den konkrete flaskehals inden for polynomiumforpligtelsesordningen afhænge af den anvendte ordning og kredsløbsstørrelsen. Men det vil altid være en af ​​følgende tre operationer: beregning af FFT'er, eksponentieringer i en kryptografisk gruppe eller Merkle-hashing. Merkle-hashing er typisk kun en flaskehals, hvis kredsløbet er lille, så vi vil ikke diskutere det yderligere. 

Polynomielle forpligtelser baseret på diskret log

I polynomielle forpligtelser baseret på hårdheden af ​​det diskrete logaritmeproblem i en kryptografisk gruppe G (KZG, Bulletproofs, Doryog Hyrax-forpligtelse), skal beviseren beregne en Pedersen vektor engagement til polynomiets koefficienter. Dette involverer en multi-eksponentiering, af størrelse lig med polynomiets grad. I SNARK'er er denne grad typisk størrelsen |C| af kredsløbet C.

Udført naivt, en multi-eksponentiering af størrelse |C| kræver omkring 1.5·|C|·log |G| ≈ 400·|C| gruppedrift, hvor |G| angiver antallet af elementer i gruppen G. Der er dog en tilgang, kaldet Pippengers algoritme, som kan reducere dette med en faktor på nogenlunde log |C|. For store kredsløb (f.eks. |C| ≥ 225), denne log |C| faktor kan konkret være 25 eller mere, det vil sige, for store kredsløb forventer vi, at Pedersen vektor-forpligtelsen kan beregnes med lidt over 10·|C| gruppedrift. Hver gruppeoperation har igen tendens til at være (som en meget hård boldbane) omkring 10 gange langsommere end en finite field operation. SNARK'er, der bruger disse polynomielle forpligtelser, er lige så dyre for P som omkring 100·|C| feltoperationer. 

Desværre har eksisterende SNARK'er yderligere omkostninger ud over ovenstående 100x faktor. For eksempel:

• Spartan's prover, som bruger Hyrax polynomielle forpligtelse, har at gøre |C|^½ mange multi-eksponentieringer hver af størrelse |C|^½, hvilket svækker speedup fra Pippengers algoritme med en faktor på cirka to. 
• In Groth16, P skal arbejde over en parringsvenlig gruppe, hvis operationer typisk er mindst 2 gange langsommere end grupper, der ikke er parringsvenlige. P skal også udføre 3 multi-eksponentieringer i stedet for 1. Kombineret resulterer dette i mindst en yderligere faktor-6 opbremsning i forhold til de 100·|C| skøn ovenfor. 
• Marlin , PlonK kræver også parringer, og deres beviser skal binde sig til betydeligt mere end 3 polynomier. 
• Til enhver SNARK, der bruger Bulletproofs (f.eks, Halo2, som er nogenlunde PlonK, men med Bulletproofs snarere end KZG polynomielle forpligtelser), skal beviseren beregne logaritmisk mange multi-eksponentieringer under "åbningsfasen" af forpligtelsesskemaet, og dette sletter stort set enhver Pippenger speedup. 

Sammenfattende synes kendte SNARK'er, der bruger Pedersen vektor-forpligtelser, at have en backend-overhead på mindst 200x og op til 1000x eller mere. 

Andre polynomielle forpligtelser

For SNARK'er, der bruger andre polynomielle forpligtelser (såsom FRE , Ligero-forpligtelse), er flaskehalsen, at beviseren skal udføre store FFT'er. For eksempel i grad-2 AIR'er produceret af Cairo (med 51 kolonner og T rækker, en pr. trin af Cairo CPU'en), udfører StarkWares installerede tester mindst 2 FFTs pr. kolonne, med en længde mellem 16 ·T , 32 ·T. Konstanterne 16 , 32 afhænger af interne parametre for FRI som indstillet af StarkWare og kan reduceres - men på bekostning af øgede verifikationsomkostninger. 

Optimistisk set en FFT med længden 32·T tager omkring 64·T·log(32T) feltmultiplikationer. Det betyder, at selv for relativt små værdier af T (f.eks, T ≥ 2²⁰), antallet af feltoperationer pr. kolonne er mindst 64·25·T= 1600·T. Så backend-overheaden ser ud til at være mindst i tusindvis. Desuden er det muligt, at store FFT'er er endnu mere flaskehalse af hukommelsesbåndbredde end af feltoperationer. 

I nogle sammenhænge kan backend-overhead af SNARK'er, der udfører store FFT'er, afbødes med en teknik, der kaldes proof aggregation. For rollups ville det betyde det P (oprulningstjenesten) opdeler et stort parti transaktioner i f.eks. 10 mindre partier. For hver lille batch i, P producerer et SNARK-bevis πi af partiets gyldighed. Men P sender ikke disse beviser til Ethereum, da dette ville føre til en næsten 10-dobling af gasomkostningerne. I stedet anvendes SNARK endnu en gang, denne gang for at producere et bevis π at fastslå det P kender π₁ , ...,π₁₀. Altså vidnet der P hævder at vide er de ti beviser π₁,…,π₁₀, og direkte vidnekontrol anvender SNARK-verifikationsproceduren på hvert af beviserne. Dette eneste bevis π er sendt til Ethereum. 

I polynomielle forpligtelser som FRI og Ligero-commit er der en stærk spænding imellem P tid og V omkostninger, med interne parametre, der fungerer som en knap, der kan afveje det ene for det andet. Siden π₁ ,…,π₁₀ ikke sendes til Ethereum, kan knappen indstilles, så disse beviser er store, og det er hurtigere at producere dem. Kun i den endelige anvendelse af SNARK, til at aggregere π₁ ,…,π₁₀ til et enkelt bevis π, skal tilsagnsordningen konfigureres for at sikre et lille bevis. 

StarkWare planlægger at implementere bevissammenlægning overhængende. Dette er også omdrejningspunktet for projekter som f.eks Plonky2.

Hvad er de andre flaskehalse i SNARK-skalerbarheden?

Dette indlæg har fokuseret på bevis tid, men andre bevisomkostninger kan også være skalerbarhedsflaskehalse. For eksempel skal proveren for mange SNARK-backends gemme flere feltelementer for hver gate i C, og disse pladsomkostninger kan være enorme. For eksempel et program ψ at køre på et sekund på en bærbar computer kan udføre måske en milliard primitive operationer på en moderne processor. Som vi har set, skal man generelt forvente C at kræve langt over 100 porte pr. sådan operation. Det betyder 100 milliarder porte, hvilket, afhængigt af SNARK, kan betyde titusinder eller hundredvis af terabyte plads til P. 

Et andet eksempel: mange populære SNARK'er (f.eks. PlonK, Marlin, Groth16) kræver en kompliceret "betroet opsætningsceremoni" for at generere en struktureret "bevisnøgle" som skal opbevares af beviseren. Så vidt jeg ved, er største sådan ceremoni genereret en bevisnøgle, der er i stand til at understøtte kredsløb med omkring 2²⁸≈250 millioner porte. Den bevisende nøgle er flere dusin gigabyte stor. 

I sammenhænge, ​​hvor bevisaggregering er mulig, kan disse flaskehalse afbødes væsentligt. 

Fremadrettet: udsigt til mere skalerbare SNARK'er

Både frontend og backend overhead kan være tre størrelsesordener eller mere. Kan vi forvente, at disse vil falde væsentligt i den nærmeste fremtid? 

Det tror jeg, vi vil - til et punkt. For det første de hurtigste backends i dag (f.eks. Spartan , Nedbremsning, og andre SNARK'er, der kombinerer sum-check protokol med polynomielle forpligtelser) har store beviser - typisk kvadratrod i kredsløbets størrelse - så folk bruger dem ikke rigtigt. Jeg forventer, at bevisstørrelsen og verifikatortiden vil blive væsentligt reduceret i den nærmeste fremtid via dybde-XNUMX-sammensætning med småsikre SNARK'er. I lighed med bevisaggregering betyder dette, at en beviser først vil generere et SNARK-bevis π med den "hurtigbevisende, storsikrede" SNARK, men ikke send π til V. Hellere, P ville bruge en lille-proof SNARK til at producere et bevis π' at den ved π, og send π' til V. Dette kunne barbere en størrelsesorden ud af backend-overhead-omkostningerne for SNARK'er, der er populære i dag. 

For det andet kan hardwareacceleration hjælpe. En meget grov generel regel er, at GPU'er kan købe en 10x speedup over CPU'er, og ASIC'er en 10x speedup over GPU'er. Jeg har dog tre bekymringer på denne front. For det første kan store FFT'er være flaskehalse af hukommelsesbåndbredde snarere end feltoperationer, så SNARK'er, der udfører sådanne FFT'er, kan se begrænsede speedups fra specialiseret hardware. For det andet, mens dette indlæg fokuserede på den polynomielle forpligtelsesflaskehals, kræver mange SNARK'er, at beviseren udfører andre operationer, der kun er lidt billigere. Så at bryde polynomiets forpligtelsesflaskehals (f.eks. fremskynde multi-eksponentiering i diskret-log-baserede SNARK'er) kan efterlade en ny flaskehalsoperation, der ikke er meget bedre end den gamle. (For eksempel har SNARK'er, herunder Groth16, Marlin og PlonK, også FFT'er, der kan bevise, ud over multi-eksponentieringer.) Endelig kan de felter og elliptiske kurver, der fører til de mest effektive SNARK'er, fortsætte med at udvikle sig i nogen tid, og det kan skabe udfordringer for ASIC-baseret bevisacceleration.

På frontend-siden kan vi i stigende grad opdage, at "CPU-emulator"-tilgangen til projekter som Cairo, RISC Zero, zkEVM'er og andre faktisk skalerer ganske godt (med hensyn til ydeevne) med kompleksiteten af ​​CPU-instruktionssæt. Faktisk er dette netop håbet for forskellige zkEVM-projekter. Dette kan betyde, at mens frontend-overhead forbliver tre størrelsesordener eller mere, formår frontends at understøtte VM'er, der i stigende grad matcher ægte CPU-arkitekturer. En modsvarende bekymring er, at frontends kan blive komplicerede og svære at revidere, efterhånden som håndkodede gadgets, der implementerer mere og mere komplicerede instruktioner, spreder sig. Formelle verifikationsmetoder vil sandsynligvis spille en vigtig rolle for at løse denne bekymring. 

Endelig kan vi i hvert fald i blockchain-applikationer opdage, at de fleste smarte kontrakter, der optræder i naturen, primært bruger enkle, SNARK-venlige instruktioner. Dette kan muliggøre lave frontend-omkostninger i praksis, samtidig med at den generelle karakter og den forbedrede udvikleroplevelse, der følger med at understøtte programmeringssprog på højt niveau som Solidity og rige instruktionssæt, inklusive dem i EVM, bevares. 

***

Justin Thaler is en lektor ved Georgetown University. Før han kom til Georgetown, tilbragte han to år som forskningsforsker ved Yahoo Labs i New York, før han var forskningsstipendiat ved Simons Institut for Theory of Computing på UC Berkeley. 

***

Tak: Jeg er taknemmelig for Elena Burger for at foreslå emnet for dette indlæg, og til Arasu Arun, Joseph Bonneauog Sam Ragsdale for indsigtsfulde kommentarer. Også en særlig tak til min redaktør, Tim Sullivan.

***

De synspunkter, der er udtrykt her, er dem fra det enkelte AH Capital Management, LLC ("a16z") personale, der er citeret, og er ikke synspunkter fra a16z eller dets tilknyttede selskaber. Visse oplysninger indeholdt heri er indhentet fra tredjepartskilder, herunder fra porteføljeselskaber af fonde forvaltet af a16z. Selvom det er taget fra kilder, der menes at være pålidelige, har a16z ikke uafhængigt verificeret sådanne oplysninger og fremsætter ingen erklæringer om informationernes vedvarende nøjagtighed eller deres passende for en given situation. Derudover kan dette indhold omfatte tredjepartsreklamer; a16z har ikke gennemgået sådanne annoncer og støtter ikke noget reklameindhold indeholdt deri.

Dette indhold er kun givet til informationsformål og bør ikke påberåbes som juridisk, forretningsmæssig, investerings- eller skatterådgivning. Du bør rådføre dig med dine egne rådgivere om disse spørgsmål. Henvisninger til værdipapirer eller digitale aktiver er kun til illustrationsformål og udgør ikke en investeringsanbefaling eller tilbud om at levere investeringsrådgivningstjenester. Ydermere er dette indhold ikke rettet mod eller beregnet til brug af nogen investorer eller potentielle investorer og kan under ingen omstændigheder stoles på, når der træffes en beslutning om at investere i en fond, der administreres af a16z. (Et tilbud om at investere i en a16z-fond vil kun blive givet af private placement-memorandummet, tegningsaftalen og anden relevant dokumentation for en sådan fond og bør læses i deres helhed.) Eventuelle investeringer eller porteføljeselskaber nævnt, refereret til eller beskrevne er ikke repræsentative for alle investeringer i køretøjer, der administreres af a16z, og der kan ikke gives sikkerhed for, at investeringerne vil være rentable, eller at andre investeringer foretaget i fremtiden vil have lignende karakteristika eller resultater. En liste over investeringer foretaget af fonde forvaltet af Andreessen Horowitz (undtagen investeringer, hvortil udstederen ikke har givet tilladelse til, at a16z offentliggør såvel som uanmeldte investeringer i offentligt handlede digitale aktiver) er tilgængelig på https://a16z.com/investments /.

Diagrammer og grafer, der er angivet i, er udelukkende til informationsformål og bør ikke stoles på, når der træffes nogen investeringsbeslutning. Tidligere resultater er ikke vejledende for fremtidige resultater. Indholdet taler kun fra den angivne dato. Alle fremskrivninger, estimater, prognoser, mål, udsigter og/eller meninger udtrykt i disse materialer kan ændres uden varsel og kan afvige fra eller være i modstrid med andres meninger. Se venligst https://a16z.com/disclosures for yderligere vigtige oplysninger.