Merjenje zmogljivosti SNARK: Frontend, backend in prihodnost

SNARK (Succinct Non-interactive Arguments of Knowledge) je pomemben kriptografski primitiv za iskanje aplikacij za razširljivost verige blokov (npr. zbiranje L2) in zasebnost. SNARK-i omogočajo nekomu dokazovanje nezaupljivemu overitelju V (npr. Ethereum blockchain), da poznajo nekatere podatke (npr. paket veljavnih transakcij). Naiven način, da bi to dokazali, bi bilo pošiljanje podatkov na V, ki lahko nato neposredno preveri njeno veljavnost. SNARK doseže enako, vendar z nižjimi stroški V. Predvsem mora biti dokaz SNARK krajši od naivnega, ki vsebuje same podatke. (Za več podrobnosti si oglejte osnutek mojega učbenika, Dokazi, argumenti in ničelno znanje. Za uvod v SNARKs glejte Sarah Meicklejohn predstavitev pri kripto a16z Poletna raziskovalna serija.)

Stroški preverjanja za SNARK se lahko razlikujejo, vendar so dobro znani in pogosto zelo dobri. na primer PlonK dokazila stanejo približno 290,000 plin za preverjanje na Ethereumu, medtem ko dokazila StarkWare stanejo približno 5 milijonov plina. SNARK-i so potencialno uporabni v različnih nastavitvah, tudi zunaj verig blokov – na primer omogočajo uporabo hitrih, a nezaupljivih strežniki in strojna oprema. 

Toda ker je preverjanje SNARK običajno poceni, so glavni dejavniki uporabnosti stroški dokazovalnika SNARK P. V tej objavi razložim, kako oceniti te stroške, da ugotovim, kdaj je smiselno uporabiti SNARK, in kako bi se lahko SNARK izboljšali v prihodnosti. Treba je omeniti, da je to hitro razvijajoč se prostor in več projektov, o katerih razpravljamo v tej objavi, aktivno izboljšuje svojo uspešnost.

Toda najprej: Kako so nameščeni SNARK-i

Pri uvajanju SNARK razvijalec običajno napiše računalniški program ψ ki kot vhod vzame podatke w za katero dokazovalec trdi, da ve (w stojala za priča), in to preveri w velja. Na primer, pri skupnih podatkih bo program preveril, ali so vse transakcije v w so digitalno podpisani, ne povzročajo padca stanja na računu pod ničlo in tako naprej. Program ψ se nato napaja skozi a Vmesnik SNARK ki ga prevede v obliko, ki je bolj primerna za uporabo tehnologije SNARK. Ta format, prijazen do SNARK, se imenuje an vmesna reprezentanca (IR). 

Običajno je IR nekakšen primerek zadovoljivosti vezja, ki je enakovreden ψ. To pomeni, da vezje C kot vhod vzame podatke w, kot tudi nekaj dodatnih vnosov, ki se običajno imenujejo "nedeterministični nasveti", in teče ψ on w. V pomoč so uporabljeni nasveti C run ψ, pri tem pa ohraniti C majhna. Na primer vsakič ψ deli dve števili x in y, količnik q in ostanek r se lahko ponudi kot nasvet Cin C lahko to enostavno preveri x = qy + r. Ta pregled je cenejši od izdelave C zaženite algoritem deljenja za izračun q in r iz nič.

Nazadnje se uporabi SNARK za zadovoljivost vezja C. To se imenuje Zaledje SNARK. Za peščico visoko strukturiranih problemov, kot je npr množenje matrik, zvitkiin več težav z grafom, obstajajo znani SNARK-i, ki se izogibajo tej paradigmi frontend/backend in s tem dosežejo veliko hitrejši preverjalnik. Toda poudarek te objave je na SNARK-ih za splošne namene.

Kot bomo videli, rastejo stroški preverjanja zaledja SNARK Cje velikost. Ohranjanje C majhna je lahko izziv, saj so vezja izjemno omejen format, v katerem je mogoče izraziti izračun. Sestavljeni so iz vrata, povezan z žice. Vsaka vrata g se napaja z nekaterimi vrednostmi in uporablja a zelo preprosta funkcija za te vrednosti. Rezultat se nato napaja v "spodnja" vrata preko žic, ki izhajajo iz g.

Razširljivost SNARK: Koliko časa v resnici traja?

Ključno vprašanje je, koliko več časa potrebuje preverjanje SNARK glede na preprosto ponovno izvajanje ψ na podatkih? Odgovor je nad glavo dokazovalnika SNARK, glede na neposredno preverjanje prič. Slednji izraz se nanaša na dejstvo, da v naivnem dokazu, v katerem P pošlje w do V, V Pregledi wveljavnost z izvršitvijo ψ na njem. 

Koristno je razdeliti obremenitev preverjalnika na "splošne stroške sprednjega dela" in "stroške zalednega dela". Če ocenjujete vezje C vrata za vrati je F krat dražji od teka ψ, potem rečemo, da so režijski stroški sprednjega dela F. Če uporabite zaledni preverjalnik za C is B krat dražje od ocenjevanja C vrata za vrati, potem rečemo, da so režijski stroški zaledja B. Skupni režijski stroški dokazovalnika so izdelka, F·B. Ta multiplikativni režijski strošek je lahko precejšen, tudi če F in B so individualno skromni. 

V praksi, F in B oba sta lahko približno 1000 ali večja. To pomeni, da so lahko skupni stroški dokazovalnika glede na neposredno preverjanje prič od 1 do 10 milijonov ali več. Program, ki se na prenosnem računalniku izvaja samo eno sekundo, lahko zlahka pripelje do preverjanja SNARK, ki zahteva desetine ali stotine dni računalniškega časa (enonitnega). Na srečo je to delo običajno vzporedno v različnih obsegih (odvisno od SNARK). 

Če povzamemo, če želite danes uporabiti SNARK v aplikaciji, potem mora veljati ena od treh stvari:

1. Neposredno preverjanje prič traja veliko manj kot eno sekundo na prenosnem računalniku.
2. Neposredno preverjanje prič je še posebej primerno za predstavitev v vezju, zato so stroški vmesnika majhni.
3. Pripravljeni ste čakati dneve, da se preverjalnik SNARK konča, in/ali plačati ogromne vzporedne računalniške vire.

TPreostanek te objave pojasnjuje, od kod izvirajo režijski stroški vhodnega in zalednega dela ter kako jih ocenjujem za različne SNARK. Nato se bomo obrnili na možnosti za izboljšanje. 

Ločevanje frontendov in backendov

Popolno ločevanje sprednjih delov od ozadij je lahko zahtevno, ker različna ozadja podpirajo različne vrste vezij. Zato se lahko vmesniki razlikujejo glede na zaledje, s katerim pričakujejo vmesnik.

Zaledja SNARK na splošno podpirajo tako imenovana aritmetična vezja, kar pomeni, da so vhodi v vezja elementi nekega končnega polja in da vrata vezja izvajajo seštevanje in množenje dveh elementov polja. Ta vezja približno ustrezajo ravnim črtnim računalniškim programom (brez vej, pogojnih stavkov itd.), ki so algebraične narave - to pomeni, da so njihov primitivni podatkovni tip elementi polja. 

Večina ozadij dejansko podpira posplošitev aritmetičnih vezij, ki se pogosto imenujejo primerki zadovoljevanja omejitev ranga 1 (R1CS). Z opazno izjemo Groth16 in njegovih predhodnikov je mogoče te SNARK-e pripraviti tako, da podpirajo tudi druge IR-je. Na primer, StarkWare uporablja nekaj, kar se imenuje Algebraic Intermediate Representation (AIR), kar je prav tako podobno pojmu, imenovanemu PlonKish aritmetizacija ki ga lahko podpirajo PlonK in druga ozadja. Sposobnost nekaterih ozadij, da podpirajo splošnejše IR-je, lahko zmanjša obremenitev čelnih koncev, ki proizvajajo te IR-je. 

Zaledja se razlikujejo tudi glede končnih polj, ki jih izvorno podpirajo. O tem bom podrobneje razpravljal v naslednjem razdelku.

Različni pristopi k frontendom

Nekateri (zelo posebni) računalniški programi seveda ustrezajo aritmetičnim vezjem. En primer je računalniški program, ki izvaja naivno množenje matrik nad nekim poljem. Toda večina računalniških programov ni ne ravnih ne algebrskih. Pogosto vključujejo pogojne stavke, operacije, kot je deljenje celih števil ali aritmetika s plavajočo vejico, ki naravno ne ustrezajo aritmetiki končnih polj, in več. V teh primerih bodo stroški vmesnika precejšnji. 

Eden od priljubljenih pristopov je izdelava vezij, ki v bistvu korak za korakom izvajajo preprost CPU, imenovan tudi virtualni stroj (VM). Oblikovalci sprednjega dela določajo niz "primitivnih operacij", ki so analogne navodilom za sestavljanje za prave računalniške procesorje. Razvijalci, ki želijo uporabljati sprednji del, bodo pisali "programe za preverjanje prič" neposredno v zbirnem jeziku ali pa v kakšnem jeziku višje ravni, kot je Solidity, in bodo svoje programe samodejno prevedli v zbirno kodo. 

Na primer StarkWare Cairo je zelo omejen zbirni jezik, v katerem navodila za sestavljanje v grobem dovoljujejo seštevanje in množenje v končnem polju, klice funkcij ter branje in pisanje v nespremenljiv (t.j. enkraten zapis) pomnilnik. Cairo VM je von Neumannova arhitektura, kar pomeni, da vezja, ki jih ustvari sprednji del, v bistvu vzamejo program Cairo kot javni vložek in "zaženejo" program na priči. Jezik Cairo je Turing Complete - kljub omejenemu naboru navodil lahko simulira bolj standardne arhitekture, čeprav je to lahko drago. Vmesni del Cairo omogoča izvajanje programov Cairo T primitivna navodila v tako imenovano »stopnjo2 ZRAK z T vrstice in približno 50 stolpce." Kaj točno to pomeni ni pomembno za to objavo, toda kar zadeva preverjalnike SNARK, to ustreza vezjem z med 50 in 100 vrati za vsako od T korake Cairo CPU. 

RISC nič ima podoben pristop kot Kairo, le da je virtualni stroj ti RISC-V arhitektura, odprtokodna arhitektura z bogatim programskim ekosistemom, ki postaja vse bolj priljubljena. Ker gre za zelo preprost nabor navodil, je oblikovanje učinkovitega čelnega vmesnika SNARK, ki ga podpira, lahko razmeroma poslušno (vsaj glede na zapletene arhitekture, kot sta x86 ali ARM). Od maja RISC Zero obrača programe izvršitve T primitivna navodila RISC-V v AIR stopnje 5 s 3T vrstice in 160 stolpce. To ustreza vezjem z najmanj 500 vrat na korak procesorja RISC-V. V bližnji prihodnosti se pričakujejo nadaljnje izboljšave.

Različni projekti zkEVM (npr. zkSync 2.0, Scroll, Polygon's zkEVM) jemljejo virtualni stroj kot (pa) virtualni stroj Ethereum. Postopek spreminjanja vsakega ukaza EVM v enakovreden »pripomoček« (tj. optimizirano vezje, ki izvaja ukaz) je bistveno bolj zapleten kot pri enostavnejših arhitekturah Cairo in RISC-V. Zaradi tega in drugih razlogov, nekaj projektov zkEVM ne implementirajo neposredno nabora navodil EVM, temveč prevajajo programe Solidity na visoki ravni v druge zbirne jezike, preden jih spremenijo v vezja. Rezultati uspešnosti teh projektov so v teku.

Projekti »emulatorja procesorja«, kot sta RISC-V in Cairo, proizvajajo eno vezje, ki lahko obravnava vse programe v povezanem zbirnem jeziku. Alternativni pristopi so "podobni ASIC-u", ki proizvajajo različna vezja za različne programe. Ta pristop, podoben ASIC-u, lahko ustvari manjša vezja za nekatere programe, še posebej, če navodilo za sestavljanje, ki ga program izvede v vsakem časovnem koraku, ni odvisno od vnosa programa. Na primer, potencialno se lahko v celoti izogne ​​obremenitvi vmesnika za ravne programe, kot je naivno matrično množenje. Toda pristop ASIC se zdi tudi zelo omejen; kolikor vem, ni znano, kako ga uporabiti za podporo zank brez vnaprej določenih meja ponovitev. 

Končna komponenta sprednjih stroškov izhaja iz dejstva, da vsi SNARK uporabljajo vezja, ki delujejo v končnih poljih. CPE na vašem prenosniku lahko pomnoži ali sešteje dve celi števili z enim strojnim ukazom. Če sprednji del izda vezje preko polja z dovolj velikimi značilnostmi, lahko v bistvu simulira to množenje ali seštevanje prek ustrezne operacije polja. Vendar pa bo izvajanje operacije polja na resničnem CPE običajno zahtevalo veliko strojnih navodil (čeprav imajo nekateri sodobni procesorji izvorno podporo za določena polja). 

Nekatera ozadja SNARK omogočajo bolj prilagodljive izbire polj kot druga. Na primer, če zaledje uporablja kriptografsko skupino G, se mora polje vezja ujemati s številom elementov v G, kar je lahko omejujoče. Poleg tega vsa polja ne podpirajo praktičnih algoritmov FFT. 

Obstaja samo en implementiran SNARK, Zaviranje, ki izvorno podpira izračune nad poljubnimi (dovolj velikimi) polji. Skupaj s svojim potomci, ima najhitrejšo znano zmogljivost konkretnega dokazovalnika tudi na področjih, ki jih podpirajo drugi SNARK-i, vendar so njegovi dokazi trenutno preveliki za številne aplikacije blockchain. Nedavno delo poskuša izboljšati velikost dokazila, vendar je dokazovalnik asimptotično počasnejši in tam zdi se ovire na praktičnost.

Nekateri projekti so se odločili za delo na poljih s posebno hitro aritmetiko. na primer Plonky2 drugi pa uporabljajo polje značilnosti 2⁶⁴ - 2³² + 1 because arithmetic in this field can be implemented several times faster than in less structured fields. However, using such a small characteristic may lead to challenges in efficiently representing integer arithmetic via field operations (e.g., multiplying two 32-bit unsigned integers might yield a result greater than the field characteristic). 

 Toda ne glede na vse, da bi vsi danes priljubljeni SNARK-i dosegli 128 bitov varnosti (brez znatnega povečanja stroškov preverjanja), morajo delati na polju, ki je večje od 2¹²⁸. Kolikor lahko povem, to pomeni, da bo vsaka terenska operacija zahtevala vsaj približno deset 64-bitnih strojnih množenj ter precej več seštevanj in bitnih operacij. Zaradi potrebe po vezjih, ki delujejo v končnih poljih, je treba upoštevati vsaj red velikosti sprednjih stroškov. 

Če povzamemo, obstoječe sprednje strani, ki uporabljajo abstrakcijo virtualnega stroja, proizvajajo vezja s 100x do 1000x vrati na korak virtualnega stroja in morda več za bolj zapletene virtualne stroje. Poleg tega je aritmetika končnih polj vsaj 10x počasnejša od analognih ukazov na sodobnih procesorjih (z možnimi izjemami, če ima procesor vgrajeno podporo za določena polja). »Pristop ASIC frontend« bi lahko zmanjšal nekatere od teh režijskih stroškov, vendar je trenutno omejen glede vrst programov, ki jih lahko podpira.

Kakšna so ozka grla v zaledju?

SNARK-ji za zadovoljivost vezja so običajno zasnovani s kombiniranjem informacijsko teoretično varnega protokola, imenovanega "polinom IOP" s kriptografskim protokolom, imenovanim "shema polinomske zaveze.” V večini primerov je konkretno ozko grlo za dokazovalnik shema polinomske zaveze. Zlasti ti SNARK-ji imajo dokazovalnik kriptografsko zavezan enemu ali več polinomom, katerih stopnja je (vsaj) |C|, število vrat v vezju C. 

Po drugi strani bo konkretno ozko grlo znotraj sheme polinomske zaveze odvisno od uporabljene sheme in velikosti vezja. Vendar bo to vedno ena od naslednjih treh operacij: računanje FFT, potenciranje v kriptografski skupini ali Merklovo zgoščevanje. Merklovo zgoščevanje je običajno ozko grlo le, če je vezje majhno, zato o tem ne bomo več razpravljali. 

Polinomske zaveze, ki temeljijo na diskretnem dnevniku

V polinomskih zavezah, ki temeljijo na trdoti problema diskretnega logaritma v kriptografski skupini G (KZG, Neprebojne zaščite, Doryin Hyrax-zaveza), mora dokazovalnik izračunati a Pedersenova vektorska zaveza na koeficiente polinoma. To vključuje večkratno potenciranje velikosti, ki je enaka stopnji polinoma. V SNARK je ta stopnja običajno velikost |C| vezja C.

Izvedeno naivno, večkratno potenciranje velikosti |C| zahteva približno 1.5·|C|·prijavi |G| ≈ 400·|C| skupinske operacije, kjer |G| označuje število elementov v skupini G. Vendar pa obstaja pristop, imenovan Pippengerjev algoritem, ki lahko to zmanjša za faktor približno log |C|. Za velika vezja (recimo |C| ≥ 225), ta dnevnik |C| faktor je lahko konkretno 25 ali več, kar pomeni, da za velika vezja pričakujemo, da je zaveza Pedersenovega vektorja lahko izračunljiva z nekaj več kot 10·|C| skupinske operacije. Vsaka skupinska operacija po vrsti je ponavadi (kot zelo grobo merilo) približno 10x počasnejša od operacije končnega polja. SNARK-i, ki uporabljajo te polinomske zaveze, so enako dragi P kot okoli 100·|C| terenske operacije. 

Na žalost imajo obstoječi SNARK dodatne režijske stroške poleg faktorja 100x zgoraj. Na primer:

• SpartanPreverjevalnik, ki uporablja zavezo Hyraxovega polinoma, mora storiti |C|^½ veliko večstopenčevanj vsake velikosti |C|^½, kar oslabi pospešek Pippengerjevega algoritma za faktor približno dva. 
• In Groth16, P mora delovati v skupini, ki je prijazna do združevanja, katere operacije so običajno vsaj 2x počasnejše od skupin, ki niso prijazne do združevanja. P mora izvesti tudi 3 večstopenčenja namesto 1. Skupaj to povzroči vsaj dodatno upočasnitev faktorja 6 glede na 100·|C| ocena zgoraj. 
• Marlin in PlonK zahtevajo tudi parjenje in njihove dokazovalce, da se zavežejo precej več kot 3 polinomom. 
• Za vsak SNARK, ki uporablja Neprebojne zaščite (npr. Halo2, kar je približno PlonK, vendar z zavezami polinoma Bulletproofs in ne KZG), mora dokazovalnik logaritmično izračunati veliko multi-eksponenticij med »odpiralno« fazo sheme zaveze, kar v veliki meri izbriše vsako Pippengerjevo pospešitev. 

Če povzamemo, zdi se, da imajo znani SNARK-ji, ki uporabljajo vektorske zaveze Pedersen, zaledne stroške vsaj 200-krat in do 1000-krat ali več. 

Druge polinomske zaveze

Za SNARK, ki uporabljajo druge polinomske zaveze (kot npr FREE in Ligero-zaveza), ozko grlo je, da mora dokazovalnik izvajati velike FFT. Na primer, v AIR-jih stopnje 2, ki jih je izdelal Cairo (z 51 stolpci in T vrstice, ena na korak CPE-ja Cairo), nameščeni preverjalnik StarkWare izvede vsaj 2 FFT-ja na stolpec, dolžine med 16 ·T in 32 ·T. Konstante 16 in 32 so odvisni od notranjih parametrov FRI, kot jih je nastavil StarkWare, in jih je mogoče zmanjšati – vendar za ceno povečanih stroškov preverjanja. 

Optimistično FFT dolžine 32·T traja približno 64·T·dnevnik (32T) množenja polja. To pomeni, da tudi pri relativno majhnih vrednostih T (npr. T ≥ 2²⁰), je število terenskih operacij na stolpec vsaj 64·25·T= 1600·T. Zdi se, da so stroški zaledja vsaj v tisočih. Poleg tega je možno, da so veliki FFT še bolj ozki zaradi pasovne širine pomnilnika kot zaradi operacij na terenu. 

V nekaterih kontekstih je mogoče zaledne stroške SNARK-jev, ki izvajajo velike FFT-je, ublažiti s tehniko, imenovano združevanje dokazov. Za zbiranje bi to pomenilo to P (storitev zbiranja) razdeli veliko skupino transakcij v, recimo, 10 manjših skupin. Za vsako majhno serijo i, P izdela dokaz SNARK πi veljavnosti serije. Ampak P ne objavi teh dokazil v Ethereumu, saj bi to povzročilo skoraj 10-kratno povečanje stroškov plina. Namesto tega se ponovno uporabi SNARK, tokrat za izdelavo dokaza π ugotavljanje tega P ve π₁ ...,π₁₀. Se pravi priča, da P trdi, da ve, je deset dokazov π₁,…,π₁₀, neposredno preverjanje prič pa uporabi postopek preverjanja SNARK za vsako dokazilo. Ta edini dokaz π je objavljen v Ethereumu. 

Pri polinomskih zavezah, kot sta FRI in Ligero-commit, je med njimi močna napetost P čas in V stroške, pri čemer notranji parametri delujejo kot gumb, ki lahko zamenja enega za drugega. Od π₁ ,…,π₁₀ niso objavljeni v Ethereumu, je mogoče gumb nastaviti tako, da so ti dokazi so velike in njihova proizvodnja je hitrejša. Samo v končni uporabi SNARK, za združevanje π₁ ,…,π₁₀ v en sam dokaz π, ali je treba shemo obveznosti konfigurirati tako, da zagotovi majhen dokaz. 

StarkWare načrtuje uvedbo združevanja dokazov neizogibno. To je tudi fokus projektov kot npr Plonky2.

Katera so druga ozka grla pri razširljivosti SNARK?

Ta objava se je osredotočila na dokazilo čas, vendar so lahko ozka grla razširljivosti tudi drugi stroški dokazovalnika. Na primer, za veliko ozadij SNARK mora preverjalnik shraniti več elementov polja za vsaka vrata C, in ti prostorski stroški so lahko ogromni. Na primer program ψ v eni sekundi na prenosnem računalniku lahko izvede morda milijardo primitivnih operacij na sodobnem procesorju. Kot smo videli, je na splošno treba pričakovati C zahtevati več kot 100 vrat na takšno operacijo. To pomeni 100 milijard vrat, kar lahko glede na SNARK pomeni desetine ali stotine terabajtov prostora za P. 

Še en primer: veliko priljubljenih SNARK (npr. PlonK, Marlin, Groth16) zahtevajo zapleteno »ceremonijo zaupanja vredne nastavitve« za ustvarjanje strukturiranega »ključa za preverjanje,« ki jih mora shraniti dokazovalnik. Kolikor vem, največja tovrstna slovesnost ustvaril dokazni ključ, ki je sposoben podpirati vezja s približno 2²⁸≈250 milijonov vrat. Dokazni ključ je velik več deset gigabajtov. 

V kontekstih, kjer je možno združevanje dokazov, je mogoče ta ozka grla bistveno ublažiti. 

Pogled naprej: možnosti za bolj razširljive SNARK-e

Tako čelni kot zadnji stroški so lahko trije ali več velikosti. Ali lahko pričakujemo, da se bodo ti v bližnji prihodnosti bistveno zmanjšali? 

Mislim, da bomo – do neke mere. Prvič, najhitrejša ozadja danes (npr. Spartan in Zaviranjein drugi SNARK-i, ki združujejo protokol preverjanja vsote s polinomskimi obveznostmi) imajo velike dokaze - običajno kvadratni koren v velikosti vezja - zato jih ljudje v resnici ne uporabljajo. Pričakujem, da se bosta velikost preverjanja in čas preverjanja v bližnji prihodnosti smiselno zmanjšala s sestavo globine ena z majhnimi SNARK-i. Podobno kot pri združevanju dokazov to pomeni, da bi preverjalnik najprej ustvaril dokaz SNARK π s "fast-prover, large-proof" SNARK, vendar ne pošlje π do V. Precej, P bi uporabil SNARK z majhnim dokazom za izdelavo dokaza π" da ve π, in pošljite π" do V. To bi lahko za red velikosti zmanjšalo zaledne režijske stroške SNARK-jev, ki so danes priljubljeni. 

Drugič, strojno pospeševanje lahko pomaga. Zelo grobo splošno pravilo je, da lahko grafični procesorji kupijo 10-kratno pospešitev v primerjavi s procesorji, ASIC-ji pa 10-kratno pospešitev v primerjavi z grafičnimi procesorji. Vendar imam na tem področju tri pomisleke. Prvič, velike FFT-je lahko omejuje pasovna širina pomnilnika in ne operacije na terenu, zato bodo SNARK-i, ki izvajajo takšne FFT-je, morda opazili omejene pospešitve zaradi specializirane strojne opreme. Drugič, medtem ko se je ta objava osredotočala na ozko grlo polinomske zaveze, mnogi SNARK-i zahtevajo, da preverjalnik izvede druge operacije, ki so le nekoliko cenejše. Torej prekinitev ozkega grla zaveze polinoma (npr. pospeševanje večstopenčevanja v SNARK-ih, ki temeljijo na diskretnem dnevniku), lahko pustijo novo operacijo ozkega grla, ki ni veliko boljša od stare. (Na primer, SNARK-ji, vključno z Groth16, Marlin in PlonK, imajo poleg multi-eksponentiranja tudi preverjevalnik FFT.) Končno se lahko polja in eliptične krivulje, ki vodijo do najučinkovitejših SNARK, še nekaj časa razvijajo, kar lahko povzroči izzive za pospeševanje dokazovalnika na osnovi ASIC.

Na sprednji strani lahko vse pogosteje ugotovimo, da se pristop »emulatorja CPU« projektov, kot so Cairo, RISC Zero, zkEVMs in drugi, dejansko precej dobro prilagaja (v smislu zmogljivosti) s kompleksnostjo nizov ukazov CPU. Dejansko je ravno to upanje različnih projektov zkEVM. To lahko pomeni, da medtem, ko sprednji del ostaja trije velikostni razredi ali več, vmesniki uspejo podpirati VM, ki se vse bolj ujemajo z resničnimi arhitekturami CPE. Nasprotna skrb je, da lahko postanejo vmesniki zapleteni in jih je težko revidirati, saj se ročno kodirani pripomočki, ki izvajajo vse bolj zapletena navodila, množijo. Formalne metode preverjanja bodo verjetno igrale pomembno vlogo pri reševanju te skrbi. 

Končno, vsaj v aplikacijah blockchain, lahko ugotovimo, da večina pametnih pogodb, ki se pojavljajo v naravi, uporablja predvsem preprosta, SNARK prijazna navodila. To lahko v praksi omogoči nizke stroške vmesnika, hkrati pa ohrani splošnost in izboljšano izkušnjo za razvijalce, ki jo prinaša podpora za programske jezike na visoki ravni, kot je Solidity, in bogati nabori navodil, vključno s tistimi iz EVM. 

***

Justin Thaler is izredni profesor na univerzi Georgetown. Preden se je pridružil Georgetownu, je bil dve leti kot raziskovalec pri Yahoo Labs v New Yorku, pred tem pa je bil raziskovalec pri Simonsov inštitut za teorijo računalništva na UC Berkeley. 

***

Zahvala: Hvaležen sem Elena Burger za predlaganje teme te objave in Arasu Arun, Joseph Bonneauin Sam Ragsdale za pronicljive komentarje. Posebna zahvala tudi mojemu uredniku, Tim Sullivan.

***

Tukaj izražena stališča so stališča posameznega citiranega osebja družbe AH Capital Management, LLC (»a16z«) in niso stališča družbe a16z ali njenih podružnic. Nekatere informacije, vsebovane tukaj, so bile pridobljene iz virov tretjih oseb, vključno s portfeljskimi družbami skladov, ki jih upravlja a16z. Čeprav so vzeti iz virov, za katere menijo, da so zanesljivi, a16z ni neodvisno preveril takih informacij in ne daje nobenih zagotovil o trajni točnosti informacij ali njihovi ustreznosti za dano situacijo. Poleg tega lahko ta vsebina vključuje oglase tretjih oseb; a16z ni pregledal takšnih oglasov in ne podpira nobene oglaševalske vsebine v njih.

Ta vsebina je na voljo samo v informativne namene in se je ne smete zanašati kot pravni, poslovni, naložbeni ali davčni nasvet. Glede teh zadev se morate posvetovati s svojimi svetovalci. Sklici na katere koli vrednostne papirje ali digitalna sredstva so samo v ilustrativne namene in ne predstavljajo naložbenega priporočila ali ponudbe za zagotavljanje investicijskih svetovalnih storitev. Poleg tega ta vsebina ni namenjena nobenim vlagateljem ali bodočim vlagateljem niti ji ni namenjena in se nanjo v nobenem primeru ne smete zanašati, ko se odločate za vlaganje v kateri koli sklad, ki ga upravlja a16z. (Ponudba za vlaganje v sklad a16z bo podana le z memorandumom o zasebni plasiranju, pogodbo o vpisu in drugo ustrezno dokumentacijo katerega koli takega sklada in jo je treba prebrati v celoti.) Vse naložbe ali portfeljske družbe, omenjene, navedene ali opisane niso reprezentativne za vse naložbe v vozila, ki jih upravlja a16z, in ni nobenega zagotovila, da bodo naložbe donosne ali da bodo imele druge naložbe v prihodnosti podobne značilnosti ali rezultate. Seznam naložb skladov, ki jih upravlja Andreessen Horowitz (razen naložb, za katere izdajatelj ni dal dovoljenja a16z za javno razkritje, ter nenapovedanih naložb v digitalna sredstva, s katerimi se javno trguje), je na voljo na https://a16z.com/investments /.

Grafi in grafi, ki so navedeni znotraj, so izključno informativne narave in se nanje ne bi smeli zanašati pri sprejemanju kakršnih koli investicijskih odločitev. Pretekla uspešnost ni pokazatelj prihodnjih rezultatov. Vsebina govori samo od navedenega datuma. Vse projekcije, ocene, napovedi, cilji, obeti in/ali mnenja, izražena v tem gradivu, se lahko spremenijo brez predhodnega obvestila in se lahko razlikujejo ali so v nasprotju z mnenji, ki so jih izrazili drugi. Za dodatne pomembne informacije obiščite https://a16z.com/disclosures.