Măsurarea performanței SNARK: front-end-uri, back-end-uri și viitor

A SNARK (Succinct Non-interactive Arguments of Knowledge) este o aplicație primitivă criptografică importantă care găsește aplicații pentru scalabilitatea blockchain (de exemplu, pachetele L2) și confidențialitate. SNARK-urile permit pe cineva să demonstreze unui verificator care nu are încredere V (de exemplu, blockchain-ul Ethereum) că cunosc anumite date (de exemplu, un lot de tranzacții valide). O modalitate naivă de a demonstra acest lucru ar fi trimiterea datelor către V, care poate apoi verifica direct valabilitatea acestuia. Un SNARK realizează același lucru, dar cu costuri mai bune V. În special, o dovadă SNARK ar trebui să fie mai scurtă decât cea naivă care cuprinde datele în sine. (Pentru mai multe detalii, vezi schița manualului meu, Dovezi, argumente și cunoștințe zero. Pentru o introducere în SNARK, vezi Sarah Meicklejohn prezentare la cripto a16z Seria de cercetare de vară.)

Costurile de verificare pentru SNARK-uri pot varia, dar sunt bine înțelese și adesea destul de bune. De exemplu, PlonK dovezile costa aproximativ 290,000 gaz pentru a verifica pe Ethereum, în timp ce dovezile lui StarkWare costă aproximativ 5 milioane de benzină. SNARK-urile sunt potențial aplicabile în diverse setări, chiar și în afara blockchain-urilor - de exemplu, permițând utilizarea rapidă, dar neîncrezătoare. servere și hardware. 

Dar, deoarece verificarea SNARK este de obicei ieftină, principalii factori determinanți ai aplicabilității sunt costurile probatorului SNARK. P. În această postare, explic cum să estimăm aceste costuri pentru a determina când este rezonabil să folosiți SNARK-urile și cum s-ar putea îmbunătăți SNARK-urile în viitor. Este de remarcat faptul că acesta este un spațiu în mișcare rapidă, iar câteva dintre proiectele discutate în această postare își îmbunătățesc în mod activ performanța.

Dar mai întâi: cum sunt implementate SNARK-urile

În implementarea SNARK, un dezvoltator scrie de obicei un program de calculator ψ care ia ca intrare datele w pe care dovatorul pretinde că îl știe (w standuri pentru martor), și verifică asta w este valabil. De exemplu, în rollup-uri, programul va verifica dacă toate tranzacțiile în w sunt semnate digital, nu fac ca soldurile contului să scadă sub zero și așa mai departe. Programul ψ este apoi alimentat printr-o Interfață SNARK care îl compilează într-un format care este mai susceptibil de aplicarea tehnologiei SNARK. Acest format prietenos cu SNARK se numește an reprezentare intermediară (IR). 

De obicei, IR este un fel de instanță de satisfacție a circuitului care este echivalentă cu ψ. Aceasta înseamnă că circuitul C ia ca intrare datele w, precum și unele intrări suplimentare numite de obicei „sfaturi nedeterministe” și rulează ψ on w. Intrările de sfaturi sunt folosite pentru a ajuta C alerga ψ, păstrând C mic. De exemplu, de fiecare dată ψ împarte două numere x și y, coeficientul q si restul r poate fi oferit ca sfat pentru C, și C pot verifica pur și simplu asta x = qy + r. Acest control este mai puțin costisitor decât efectuarea C rulați un algoritm de divizare pentru a calcula q și r de la zero.

În cele din urmă, se aplică un SNARK pentru satisfacția circuitului C. Aceasta se numește Backend SNARK. Pentru o mână de probleme foarte structurate, cum ar fi multiplicarea matricei, circumvoluții, și mai multe probleme de grafic, există SNARK-uri cunoscute care evită această paradigmă frontend/backend și, prin urmare, obțin un prover mult mai rapid. Dar accentul acestei postări este pe SNARK-urile de uz general.

După cum vom vedea, costurile prover ale backend-ului SNARK cresc cu C„s mărimea. Păstrarea C mic poate fi o provocare, deoarece circuitele sunt un format extrem de limitat în care se poate exprima un calcul. Ele constau din porti, conectat de fire. Fiecare poartă g este alimentat cu unele valori și aplică a foarte funcție simplă la acele valori. Rezultatul este apoi introdus în porțile „din aval” prin firele care emană din g.

Scalabilitate SNARK: Cât timp durează cu adevărat?

Întrebarea cheie este, cât mai mult timp durează proba SNARK, în comparație cu simpla reexecuție ψ pe date? Răspunsul este doveditor deasupra capului de SNARK, relativ la verificarea directă a martorilor. Această din urmă expresie se referă la faptul că, în proba naivă în care P trimite w la V, V verificări wvalabilitatea lui prin executare ψ pe ea. 

Este util să împărțiți suprafața de probă în „frontend overhead” și „backend overhead”. Dacă se evaluează circuitul C poarta-cu-poarta este F ori mai scump decât alergatul ψ, atunci spunem că suprafața frontală este F. Dacă aplicați proba backend la C is B ori mai scump decât evaluarea C poarta cu poarta, atunci spunem ca suprafata de backend este B. Suprafața totală a doveditorului este produs, F·B. Această suprasarcină multiplicativă poate fi substanțială chiar dacă F și B sunt modeste individual. 

In practica, F și B ambele pot fi de aproximativ 1000 sau mai mari. Aceasta înseamnă că costul general total al doveditorului în raport cu verificarea directă a martorilor poate fi de la 1 milion până la 10 milioane sau mai mult. Un program care rulează doar o secundă pe un laptop poate duce cu ușurință la un prover SNARK care necesită zeci sau sute de zile de timp de calcul (cu un singur thread). Din fericire, această lucrare este de obicei paralelizabilă în diferite măsuri (în funcție de SNARK). 

În rezumat, dacă doriți să utilizați un SNARK într-o aplicație astăzi, atunci unul dintre cele trei lucruri trebuie să fie adevărat:

1. Verificarea directă a martorilor durează mult mai puțin de o secundă pe un laptop.
2. Verificarea directă a martorilor este deosebit de susceptibilă de reprezentare într-un circuit, astfel încât suprafața frontală este mică.
3. Sunteți dispuși să așteptați zile până la terminarea probei SNARK și/sau să plătiți pentru resurse de calcul paralele uriașe.

Trestul acestei postări explică de unde provin costurile generale de front-end și backend și cum le estimez pentru diferite SNARK-uri. Ne vom întoarce apoi la perspectivele de îmbunătățire. 

Separarea front-end-urilor și backend-urilor

Separarea completă a front-end-urilor de backend-uri poate fi o provocare, deoarece backend-uri diferite suportă diferite tipuri de circuite. Prin urmare, front-end-urile pot diferi în funcție de backend-ul cu care se așteaptă să interfațeze.

Backend-urile SNARK suportă în general așa-numitele circuite aritmetice, ceea ce înseamnă că intrările în circuite sunt elemente ale unui câmp finit și că porțile circuitului efectuează adunarea și multiplicarea a două elemente de câmp. Aceste circuite corespund aproximativ programelor de calculator în linie dreaptă (fără ramuri, instrucțiuni condiționale și așa mai departe) care sunt de natură algebrică - adică tipul lor primitiv de date este elementele de câmp. 

Majoritatea backend-urilor acceptă de fapt o generalizare a circuitelor aritmetice numite adesea instanțe de satisfacție a constrângerilor de rang 1 (R1CS). Cu excepția notabilă a Creșterea16 și predecesorii săi, aceste SNARK-uri pot fi făcute să suporte și alte IR-uri. De exemplu, StarkWare folosește ceva numit Reprezentare intermediară algebrică (AIR), care este, de asemenea, similar cu o noțiune numită Aritmetizarea PlonKish care poate fi susținut de PlonK și alte backend-uri. Capacitatea unor backend-uri de a suporta IR-uri mai generale poate reduce supraîncărcarea front-end-urilor care produc acele IR. 

Backend-urile variază și în ceea ce privește câmpurile finite pe care le suportă în mod nativ. Voi discuta acest lucru în continuare în secțiunea următoare.

Diverse abordări ale front-end-urilor

Unele programe de calculator (foarte speciale) corespund în mod natural circuitelor aritmetice. Un exemplu este programul de calculator care realizează înmulțirea naivă a matricelor pe un anumit câmp. Dar majoritatea programelor de calculator nu sunt nici drepte, nici algebrice. Ele implică adesea declarații condiționate, operații precum diviziunea întregului sau aritmetica în virgulă mobilă care nu corespund în mod natural aritmeticii câmpurilor finite și multe altele. În aceste cazuri, supraîncărcarea frontală va fi substanțială. 

O abordare frontală populară este de a produce circuite care, în esență, execută pas cu pas un CPU simplu, numit și mașină virtuală (VM). Designerii front-end specifică un set de „operații primitive” analoge instrucțiunilor de asamblare pentru procesoarele computerizate reale. Dezvoltatorii care doresc să folosească frontend-ul fie vor scrie „programe de verificare a martorilor” direct în limbajul de asamblare, fie într-un limbaj de nivel superior, cum ar fi Solidity, și vor avea programele lor compilate automat în codul de asamblare. 

De exemplu, StarkWare's Cairo este un limbaj de asamblare foarte limitat în care instrucțiunile de asamblare permit aproximativ adăugarea și înmulțirea pe un câmp finit, apeluri de funcții și citește și scrie într-o memorie imuabilă (adică, scriere o singură dată). Cairo VM este o arhitectură von Neumann, ceea ce înseamnă că circuitele produse de front-end iau în esență un program Cairo ca intrare publică și „rulează” programul pe martor. Limbajul Cairo este Turing Complete - în ciuda setului său limitat de instrucțiuni, poate simula mai multe arhitecturi standard, deși acest lucru poate fi costisitor. Interfața Cairo transformă programele Cairo în execuție T instrucțiuni primitive în ceea ce se numește „grad2 AER cu T rânduri și despre 50 coloane.” Ce exact asta inseamna nu este important pentru acest post, dar în ceea ce privește probatorii SNARK, acesta corespunde circuitelor cu între 50 și 100 de porți pentru fiecare dintre T pașii CPU Cairo. 

RISC Zero are o abordare similară față de Cairo, dar mașina virtuală fiind așa-numita Arhitectura RISC-V, o arhitectură open-source cu un ecosistem software bogat, care crește în popularitate. Ca un set de instrucțiuni foarte simplu, proiectarea unui frontend SNARK eficient care să-l suporte poate fi relativ manevrabilă (cel puțin în raport cu arhitecturile complicate, cum ar fi x86 sau ARM). Din mai, RISC Zero transformă programele executând T instrucțiuni primitive RISC-V în AIR de gradul-5 cu 3T rânduri și 160 coloane. Aceasta corespunde circuitelor cu cel puțin 500 porți pe pas ale procesorului RISC-V. Sunt anticipate îmbunătățiri suplimentare în viitorul apropiat.

Diferitele proiecte zkEVM (de exemplu, zkSync 2.0, Scroll, zkEVM de la Polygon) iau mașina virtuală ca fiind (duh) mașina virtuală Ethereum. Procesul de transformare a fiecărei instrucțiuni EVM într-un „gadget” echivalent (adică, un circuit optimizat care implementează instrucțiunea) este substanțial mai implicat decât pentru arhitecturile mai simple Cairo și RISC-V. Din acest motiv și din alte motive, unele dintre proiectele zkEVM nu implementează direct setul de instrucțiuni EVM, ci mai degrabă compilează programe Solidity de nivel înalt în alte limbaje de asamblare înainte de a le transforma în circuite. Rezultatele de performanță din aceste proiecte sunt în așteptare.

Proiectele „emulator CPU” precum RISC-V și Cairo produc un singur circuit care poate gestiona toate programele în limbajul de asamblare asociat. Abordările alternative sunt „asemănătoare cu ASIC”, producând circuite diferite pentru diferite programe. Această abordare asemănătoare ASIC poate produce circuite mai mici pentru unele programe, mai ales când instrucțiunea de asamblare pe care programul le execută la fiecare pas de timp nu depinde de intrarea programului. De exemplu, poate evita în întregime supraîncărcarea frontală pentru programe în linie dreaptă, cum ar fi multiplicarea naivă a matricei. Dar abordarea ASIC pare de asemenea foarte limitată; din câte știu eu, nu se știe cum să-l folosească pentru a susține bucle fără limite de iterație predeterminate. 

Componenta finală a supraîncărcării frontend vine din faptul că toate SNARK-urile folosesc circuite care operează pe câmpuri finite. Procesorul de pe laptop poate multiplica sau adăuga două numere întregi cu o singură instrucțiune de mașină. Dacă un front-end scoate la ieșire un circuit pe un câmp cu caracteristică suficient de mare, în esență poate simula acea multiplicare sau adunare prin operația de câmp corespunzătoare. Cu toate acestea, implementarea operațiunii pe teren pe un CPU real va necesita de obicei multe instrucțiuni ale mașinii (deși unele procesoare moderne au suport nativ pentru anumite câmpuri). 

Unele backend-uri SNARK permit alegeri de câmp mai flexibile decât altele. De exemplu, dacă backend-ul folosește un grup criptografic G, câmpul circuitului trebuie să se potrivească cu numărul de elemente din G, ceea ce poate fi limitativ. În plus, nu toate câmpurile acceptă algoritmi FFT practici. 

Există un singur SNARK implementat, Frânare, care acceptă în mod nativ calcule pe câmpuri arbitrare (suficient de mari). Împreună cu ea descendenţi, are cea mai rapidă performanță cunoscută de dovezire a betonului chiar și în domeniile pe care alte SNARK-uri le suportă, dar dovezile sale sunt în prezent prea mari pentru multe aplicații blockchain. Munca recenta încearcă să îmbunătățească dimensiunea probei, dar probatorul este asimptotic mai lent și acolo pare a fi bariere la practic.

Unele proiecte au ales să lucreze peste domenii cu aritmetică deosebit de rapidă. De exemplu, Plonky2 iar alții folosesc un câmp de caracteristică 2⁶⁴ - 2³² + 1 deoarece aritmetica în acest domeniu poate fi implementată de câteva ori mai rapid decât în ​​câmpurile mai puțin structurate. Cu toate acestea, utilizarea unei astfel de caracteristici mici poate duce la provocări în reprezentarea eficientă a aritmeticii întregi prin operații de câmp (de exemplu, înmulțirea a două numere întregi fără semn pe 32 de biți ar putea produce un rezultat mai mare decât caracteristica câmpului). 

 Dar indiferent de ce, pentru ca toate SNARK-urile populare de astăzi să atingă 128 de biți de securitate (fără o creștere semnificativă a costurilor de verificare), acestea trebuie să lucreze pe un câmp de dimensiune mai mare de 2.¹²⁸. Din câte îmi pot da seama, asta înseamnă că fiecare operațiune de câmp va necesita cel puțin aproximativ zece înmulțiri de mașini pe 64 de biți și mult mai multe adunări și operații pe biți. Prin urmare, ar trebui să se ia în considerare cel puțin un ordin de mărime supraîncărcarea frontală din cauza necesității de circuite care funcționează pe câmpuri finite. 

Pentru a rezuma, front-end-urile existente care folosesc o abstractizare a unei mașini virtuale produc circuite cu porți de 100x până la 1000x pe pas de mașină virtuală și, posibil, mai multe pentru mașinile virtuale mai complicate. În plus, aritmetica câmpurilor finite este de cel puțin 10 ori mai lentă decât instrucțiunile analoge de pe procesoarele moderne (cu posibile excepții dacă procesorul are suport încorporat pentru anumite câmpuri). O „abordare frontală ASIC” ar putea reduce unele dintre aceste cheltuieli generale, dar este în prezent limitată în ceea ce privește tipurile de programe pe care le poate suporta.

Care sunt blocajele backend?

SNARK-urile pentru satisfacția circuitului sunt de obicei proiectate prin combinarea unui protocol securizat din punct de vedere teoretic al informațiilor numit „IOP polinom” cu un protocol criptografic numit „schema de angajament polinomial.” În cele mai multe cazuri, blocajul concret pentru probator este schema de angajament polinomial. În special, aceste SNARK-uri au doveditorul se angajează criptografic la unul sau mai multe polinoame al căror grad este (cel puțin) |C|, numărul de porți din circuit C. 

La rândul său, blocajul concret în cadrul schemei de angajare polinomială va depinde de schema utilizată și de dimensiunea circuitului. Dar va fi întotdeauna una dintre următoarele trei operațiuni: calcularea FFT-urilor, exponențiații într-un grup criptografic sau Merkle-hashing. Merkle-hashing este de obicei un blocaj numai dacă circuitul este mic, așa că nu vom discuta mai departe. 

Angajamente polinomiale bazate pe log discret

În angajamente polinomiale bazate pe duritatea problemei logaritmului discret într-un grup criptografic G (KZG, Antiglonțuri, dory, și Hyrax-commit), probatorul trebuie să calculeze a Angajamentul vectorului Pedersen la coeficienții polinomului. Aceasta implică o exponențiere multiplă, de mărime egală cu gradul polinomului. În SNARK, acest grad este de obicei dimensiunea |C| circuitului C.

Făcută naiv, o multi-exponentiare a dimensiunii |C| necesită aproximativ 1.5·|C|·log |G| ≈ 400·|C| operațiuni de grup, unde |G| denotă numărul de elemente din grup G. Cu toate acestea, există o abordare, numită algoritmul lui Pippenger, care poate reduce acest lucru cu un factor de aproximativ log |C|. Pentru circuite mari (să zicem, |C| ≥ 225), acest jurnal |C| factorul poate fi concret 25 sau mai mult, adică pentru circuite mari, ne așteptăm ca angajamentul vectorului Pedersen să fie calculat cu puțin peste 10·|C| operațiuni de grup. Fiecare operațiune de grup, la rândul său, tinde să fie (ca un joc foarte dur) de aproximativ 10 ori mai lentă decât o operațiune în câmp finit. SNARK-urile care folosesc aceste angajamente polinomiale sunt la fel de scumpe pentru P ca aproximativ 100·|C| Operațiuni pe teren. 

Din păcate, SNARK-urile existente au costuri generale suplimentare pe lângă factorul de 100x de mai sus. De exemplu:

• SpartanDemonstratorul lui, care folosește angajamentul polinom Hyrax, are de făcut |C|^½ multe exponențiații multiple fiecare de dimensiune |C|^½, slăbind accelerarea de la algoritmul lui Pippenger cu un factor de aproximativ doi. 
• In Creșterea16, P trebuie să lucreze peste un grup prietenos pentru asociere, ale cărui operațiuni sunt de obicei de cel puțin 2 ori mai lente decât grupurile care nu sunt prietenoase pentru asociere. P trebuie să efectueze, de asemenea, 3 exponențiații multiple în loc de 1. Combinat, acest lucru are ca rezultat cel puțin o încetinire suplimentară a factorului 6 față de 100.·|C| estimarea de mai sus. 
• Marlin și PlonK necesită, de asemenea, perechi, iar probatorii lor să se angajeze la mult mai mult de 3 polinoame. 
• Pentru orice SNARK care folosește Antiglonțuri (de exemplu, Halo2, care este aproximativ PlonK, dar cu Bulletproofs mai degrabă decât angajamente polinomiale KZG), probatorul trebuie să calculeze logaritmic multe exponențiații multiple în timpul fazei de „deschidere” a schemei de angajare, iar acest lucru șterge în mare măsură orice accelerare Pippenger. 

În rezumat, SNARK-urile cunoscute care utilizează angajamente vectoriale Pedersen par să aibă o supraîncărcare a backend-ului de cel puțin 200x și până la 1000x sau mai mult. 

Alte angajamente polinomiale

Pentru SNARK-uri care utilizează alte angajamente polinomiale (cum ar fi GRATUIT și Ligero-commit), obstacolul este că probatorul trebuie să efectueze FFT mari. De exemplu, în AIR de gradul 2 produse de Cairo (cu 51 de coloane și T rânduri, câte unul pe pas al procesorului Cairo), probatorul instalat de la StarkWare face cel puțin 2 FFT pe coloană, cu lungimea între 16 ·T și 32 ·T. Constantele 16 și 32 depind de parametrii interni ai FRI, așa cum sunt stabiliți de StarkWare și pot fi reduse, dar cu costul creșterii costurilor de verificare. 

În mod optimist, o FFT de lungime 32·T durează aproximativ 64·T·jurnal (32T) înmulțiri de câmp. Aceasta înseamnă că chiar și pentru valori relativ mici de T (de exemplu, T ≥ 2²⁰), numărul de operațiuni pe teren pe coloană este de cel puțin 64·25·T= 1600·T. Așadar, partea de sus a backend-ului pare să fie cel puțin în mii. În plus, este posibil ca FFT-urile mari să fie și mai blocate din cauza lățimii de bandă a memoriei decât prin operațiunile pe teren. 

În unele contexte, supraîncărcarea de backend a SNARK-urilor care efectuează FFT mari poate fi atenuată cu o tehnică numită agregare a probelor. Pentru rollup-uri, asta ar însemna că P (serviciul de acumulare) împarte un lot mare de tranzacții în, să zicem, 10 loturi mai mici. Pentru fiecare lot mic i, P produce o dovadă SNARK πi de valabilitatea lotului. Dar P nu postează aceste dovezi pe Ethereum, deoarece acest lucru ar duce la o creștere de aproape 10 ori a costurilor cu gazele. În schimb, SNARK este aplicat din nou, de data aceasta pentru a produce o dovadă π stabilind ca P știe π₁ ...,π₁₀. Adică martorul că P pretinde că știe sunt cele zece dovezi π₁,…,π₁₀, iar verificarea directă a martorilor aplică procedura de verificare SNARK pentru fiecare dintre dovezi. Această singură dovadă π este postat pe Ethereum. 

În angajamentele polinomiale, cum ar fi FRI și Ligero-commit, există o tensiune puternică între P timp și V costuri, cu parametrii interni acționând ca un buton care poate schimba unul cu celălalt. De cand π₁ ,…,π₁₀ nu sunt postate pe Ethereum, butonul poate fi reglat astfel încât aceste dovezi sunt mari, iar producerea lor este mai rapidă. Doar în aplicarea finală a SNARK, pentru a agrega π₁ ,…,π₁₀ într-o singură dovadă π, trebuie configurată schema de angajament pentru a asigura o mică dovadă. 

StarkWare intenționează să implementeze agregarea de probe iminent. Acesta este și punctul central al proiectelor precum Plonky2.

Care sunt celelalte blocaje ale scalabilității SNARK?

Această postare s-a concentrat pe doveditor timp, dar alte costuri ale dovezilor pot fi, de asemenea, blocaje de scalabilitate. De exemplu, pentru multe backend-uri SNARK, probatorul trebuie să stocheze mai multe elemente de câmp pentru fiecare poartă C, iar acest cost de spațiu poate fi uriaș. De exemplu, un program ψ rularea într-o secundă pe un laptop poate efectua poate un miliard de operațiuni primitive pe un procesor modern. După cum am văzut, în general ar trebui să ne așteptăm C pentru a necesita mult peste 100 de porți pentru o astfel de operațiune. Aceasta înseamnă 100 de miliarde de porți, care, în funcție de SNARK, ar putea însemna zeci sau sute de terabytes de spațiu pentru P. 

Un alt exemplu: multe SNARK populare (de exemplu, PlonK, Marlin, Creșterea16) necesită o „ceremonie de configurare de încredere” complicată pentru a genera o „cheie de demonstrare” structurată, care trebuie păstrat de doveditor. Din câte știu eu, cea mai mare astfel de ceremonie a generat o cheie doveditoare capabilă să susțină circuite cu aproximativ 2²⁸≈250 de milioane de porți. Cheia de dovedire are o dimensiune de câteva zeci de gigaocteți. 

În contextele în care agregarea dovezilor este posibilă, aceste blocaje pot fi atenuate în mod substanțial. 

Privind în perspectivă: perspective pentru SNARK-uri mai scalabile

Atât costurile pentru front-end, cât și cele pentru backend pot fi de trei ordine de mărime sau mai mult. Ne putem aștepta ca acestea să scadă substanțial în viitorul apropiat? 

Cred că vom face - până la un punct. În primul rând, cele mai rapide backend-uri de astăzi (de exemplu, Spartan și Frânare, și alte SNARK-uri care combină protocolul de verificare a sumei cu angajamente polinomiale) au dovezi mari - de obicei rădăcină pătrată în dimensiunea circuitului - astfel încât oamenii nu le folosesc cu adevărat. Mă aștept ca dimensiunea probei și timpul de verificare să fie reduse semnificativ în viitorul apropiat prin compoziția depth-one cu SNARK-uri cu probe mici. Similar cu agregarea dovezilor, aceasta înseamnă că un probator va genera mai întâi o dovadă SNARK π cu „fast-prover, large-proof” SNARK, dar nu trimite π la V. Mai degraba, P ar folosi un SNARK cu dovadă mică pentru a produce o dovadă π" ca stie π, si trimite π" la V. Acest lucru ar putea reduce un ordin de mărime din costurile de bază ale SNARK-urilor care sunt populare astăzi. 

În al doilea rând, accelerarea hardware poate ajuta. O regulă generală foarte aspră este că GPU-urile pot cumpăra o viteză de 10 ori peste procesoare, iar ASIC-urile o viteză de 10 ori peste GPU. Cu toate acestea, am trei preocupări pe acest front. În primul rând, FFT-urile mari pot fi blocate de lățimea de bandă a memoriei, mai degrabă decât de operațiunile pe teren, astfel încât SNARK-urile care efectuează astfel de FFT pot vedea accelerații limitate din partea hardware-ului specializat. În al doilea rând, în timp ce această postare s-a concentrat pe blocajul angajamentului polinomial, multe SNARK-uri solicită dovetorului să facă alte operațiuni care sunt doar puțin mai puțin costisitoare. Deci, ruperea blocajului de angajament polinom (de exemplu, accelerarea exponentiarilor multiple în SNARK-uri bazate pe jurnal discret) poate lăsa o nouă operațiune de blocaj care nu este cu mult mai bună decât cea veche. (De exemplu, SNARK-urile, inclusiv Groth16, Marlin și PlonK au, de asemenea, dovezitorul face FFT, pe lângă exponențiații multiple.) În cele din urmă, câmpurile și curbele eliptice care duc la cele mai eficiente SNARK-uri pot continua să evolueze de ceva timp, ceea ce poate crea provocări pentru accelerarea probelor bazate pe ASIC.

Pe partea de front-end, s-ar putea să descoperim din ce în ce mai mult că abordarea „emulator CPU” a proiectelor precum Cairo, RISC Zero, zkEVM-uri și altele se scalează destul de bine (în termeni de performanță) cu complexitatea setului de instrucțiuni CPU. Într-adevăr, aceasta este tocmai speranța diferitelor proiecte zkEVM. Acest lucru poate însemna că, în timp ce suprafața frontală rămâne de trei ordine de mărime sau mai mult, front-end-urile reușesc să accepte VM-uri care se potrivesc din ce în ce mai mult cu arhitecturile CPU reale. O preocupare compensatorie este că front-end-urile pot deveni complicate și dificil de auditat, deoarece gadgeturile codificate manual care implementează instrucțiuni din ce în ce mai complicate proliferează. Metodele formale de verificare vor juca probabil un rol important în abordarea acestei preocupări. 

În cele din urmă, cel puțin în aplicațiile blockchain, putem descoperi că majoritatea contractelor inteligente care apar în sălbăticie folosesc în principal instrucțiuni simple, prietenoase cu SNARK. Acest lucru poate permite în practică costuri generale reduse pentru frontend, păstrând în același timp generalitatea și experiența îmbunătățită a dezvoltatorului care vine cu suportarea limbajelor de programare de nivel înalt precum Solidity și seturi de instrucțiuni bogate, inclusiv cele ale EVM. 

***

Justin Thaler is profesor asociat la Universitatea Georgetown. Înainte de a se alătura Georgetown, a petrecut doi ani ca cercetător la Yahoo Labs din New York, înainte de care a fost cercetător la Institutul Simons pentru Teoria Calculului la UC Berkeley. 

***

Mulțumiri: îi sunt recunoscător Elena Burger pentru propunerea subiectului acestei postări și să Arasu Arun, Joseph Bonneau, și Sam Ragsdale pentru comentarii perspicace. Mulțumiri speciale și editorului meu, Tim Sullivan.

***

Părerile exprimate aici sunt cele ale personalului individual AH Capital Management, LLC („a16z”) citat și nu sunt punctele de vedere ale a16z sau ale afiliaților săi. Anumite informații conținute aici au fost obținute din surse terțe, inclusiv de la companii de portofoliu de fonduri administrate de a16z. Deși este luat din surse considerate a fi de încredere, a16z nu a verificat în mod independent astfel de informații și nu face nicio declarație cu privire la acuratețea durabilă a informațiilor sau adecvarea lor pentru o anumită situație. În plus, acest conținut poate include reclame de la terți; a16z nu a revizuit astfel de reclame și nu aprobă niciun conținut publicitar conținut în acestea.

Acest conținut este furnizat doar în scop informativ și nu ar trebui să fie bazat pe consiliere juridică, de afaceri, de investiții sau fiscală. Ar trebui să vă consultați propriii consilieri cu privire la aceste aspecte. Referințele la orice titluri de valoare sau active digitale au doar scop ilustrativ și nu constituie o recomandare de investiții sau o ofertă de a oferi servicii de consiliere în materie de investiții. În plus, acest conținut nu este îndreptat și nici nu este destinat utilizării de către niciun investitor sau potențial investitor și nu poate fi bazat în nicio circumstanță atunci când se ia o decizie de a investi într-un fond administrat de a16z. (Ofertă de a investi într-un fond a16z va fi făcută numai prin memoriul de plasament privat, acordul de subscriere și alte documente relevante ale oricărui astfel de fond și trebuie citită în întregime.) Orice investiții sau companii de portofoliu menționate, la care se face referire sau descrise nu sunt reprezentative pentru toate investițiile în vehicule administrate de a16z și nu poate exista nicio asigurare că investițiile vor fi profitabile sau că alte investiții realizate în viitor vor avea caracteristici sau rezultate similare. O listă a investițiilor realizate de fondurile gestionate de Andreessen Horowitz (excluzând investițiile pentru care emitentul nu a oferit permisiunea ca a16z să dezvăluie public, precum și investițiile neanunțate în active digitale tranzacționate public) este disponibilă la https://a16z.com/investments /.

Diagramele și graficele furnizate în cadrul sunt doar în scop informativ și nu trebuie să se bazeze pe acestea atunci când se ia vreo decizie de investiție. Performanța trecută nu indică rezultatele viitoare. Conținutul vorbește doar de la data indicată. Orice previziuni, estimări, prognoze, obiective, perspective și/sau opinii exprimate în aceste materiale pot fi modificate fără notificare și pot diferi sau pot fi contrare opiniilor exprimate de alții. Vă rugăm să consultați https://a16z.com/disclosures pentru informații suplimentare importante.