Misurare le prestazioni di SNARK: frontend, backend e futuro

A SNARK (Succinct Non-interactive Arguments of Knowledge) è un'importante primitiva crittografica che trova applicazioni per la scalabilità della blockchain (ad esempio, rollup L2) e la privacy. Gli SNARK consentono a qualcuno di dimostrare a un verificatore diffidente V (ad esempio, la blockchain di Ethereum) di conoscere alcuni dati (ad esempio, un batch di transazioni valide). Un modo ingenuo per dimostrarlo sarebbe inviare i dati a V, che potrà poi verificarne direttamente la validità. Uno SNARK ottiene lo stesso risultato, ma con costi migliori V. In particolare, una dimostrazione SNARK dovrebbe essere più breve di quella ingenua comprendente i dati stessi. (Per maggiori dettagli, vedere la bozza del mio libro di testo, Dimostrazioni, argomenti e conoscenza zero. Per un'introduzione a SNARKs, vedere Sarah Meicklejohn presentazione alla crittografia a16z Serie di ricerche estive.)

I costi di verifica per SNARK possono variare, ma sono ben compresi e spesso abbastanza buoni. Per esempio, PlonK le prove costano circa 290,000 gas da verificare su Ethereum, mentre le prove di StarkWare costano circa 5 milioni di gas. Gli SNARK sono potenzialmente applicabili in diversi contesti anche al di fuori delle blockchain, ad esempio consentendo l’uso di soluzioni veloci ma non affidabili server ed hardware. 

Ma poiché la verifica SNARK è generalmente economica, i principali determinanti dell’applicabilità sono i costi del dimostratore SNARK P. In questo post spiego come stimare questi costi per determinare quando è ragionevole utilizzare SNARK e come SNARK potrebbe migliorare in futuro. Vale la pena notare che questo è uno spazio in rapida evoluzione e molti dei progetti discussi in questo post stanno migliorando attivamente le loro prestazioni.

Ma prima: come vengono implementati gli SNARK

Nella distribuzione SNARK uno sviluppatore in genere scrive un programma per computer ψ che prende come input i dati w che il prover afferma di sapere (w sta per testimoniare) e lo controlla w è valido. Ad esempio, nei rollup, il programma controllerà che tutte le transazioni siano state effettuate w sono firmati digitalmente, non fanno sì che i saldi dei conti scendano sotto lo zero e così via. Il programma ψ viene quindi alimentato attraverso a Front-end SNARK che lo compila in un formato più adatto all'applicazione della tecnologia SNARK. Questo formato compatibile con SNARK è chiamato an rappresentazione intermedia (ANDARE). 

In genere, l'IR è una sorta di istanza di soddisfacibilità del circuito equivalente a ψ. Ciò significa che il circuito C prende come input i dati w, così come alcuni input extra tipicamente chiamati "consigli non deterministici" e viene eseguito ψ on w. Gli input di consulenza vengono utilizzati per aiutare C eseguire il ψ, pur mantenendo C piccolo. Ad esempio, ogni volta ψ divide due numeri x ed y, il quoziente q e resto r può essere fornito come consiglio a Ce C puoi semplicemente verificarlo x = qy + r. Questo controllo è meno costoso che effettuarlo C eseguire un algoritmo di divisione per calcolare q ed r da zero.

Infine, viene applicato uno SNARK per la soddisfacibilità del circuito C. Questo si chiama il Back-end SNARK. Per una manciata di problemi altamente strutturati come moltiplicazione della matrice, convoluzionie diversi problemi sui grafici, esistono SNARK noti che evitano questo paradigma frontend/backend e quindi ottengono un dimostratore molto più veloce. Ma il focus di questo post è sugli SNARK di uso generale.

Come vedremo, i costi del prover del backend SNARK crescono con l’aumentare dei costi C'S misurare. Mantenere C piccolo può essere impegnativo, perché i circuiti sono un formato estremamente limitato in cui esprimere un calcolo. Sono costituiti da cancelli, collegato da fili. Ogni cancello g viene alimentato con alcuni valori e applica a molto funzione semplice a quei valori. Il risultato viene quindi immesso nei cancelli “a valle” tramite i fili provenienti da g.

Scalabilità SNARK: quanto tempo ci vuole davvero?

La domanda chiave è: quanto tempo impiega il prover SNARK rispetto alla semplice riesecuzione? ψ sui dati? La risposta è la prover in testa dello SNARK, relativo a controllo diretto dei testimoni. Quest'ultima espressione si riferisce al fatto che, nella prova ingenua in cui P invia w a V, V controlli wla validità eseguendo ψ su di esso. 

È utile suddividere l'overhead del prover in "overhead frontend" e "overhead backend". Se si valuta il circuito C cancello per cancello lo è F volte più costoso della corsa ψ, allora diciamo che il sovraccarico del frontend è F. Se si applica il dimostratore backend a C is B volte più costoso della valutazione C gate-by-gate, allora diciamo che il sovraccarico del backend è B. Il sovraccarico totale del prover è il Prodotto, F·B. Questo sovraccarico moltiplicativo può essere sostanziale anche se F ed B sono individualmente modesti. 

In pratica, F ed B possono essere entrambi circa 1000 o più. Ciò significa che il costo totale del prover relativo al controllo diretto dei testimoni può essere compreso tra 1 e 10 milioni o più. Un programma che viene eseguito solo per un secondo su un laptop può facilmente portare a un prover SNARK che richiede decine o centinaia di giorni di tempo di calcolo (a thread singolo). Fortunatamente, questo lavoro è tipicamente parallelizzabile in varia misura (a seconda dello SNARK). 

In sintesi, se oggi desideri utilizzare SNARK in un'applicazione, è necessario che una delle tre cose sia vera:

1. Il controllo diretto dei testimoni richiede molto meno di un secondo su un laptop.
2. Il controllo diretto dei testimoni è particolarmente adatto alla rappresentazione in un circuito, quindi il sovraccarico del frontend è ridotto.
3. Sei disposto ad aspettare giorni prima che il prover SNARK finisca e/o a pagare per enormi risorse di calcolo parallelo.

TIl resto di questo post spiega da dove provengono i costi generali di frontend e backend e come li stimo per i diversi SNARK. Passeremo poi alle prospettive di miglioramento. 

Separare frontend e backend

Separare completamente i frontend dai backend può essere difficile perché backend diversi supportano diversi tipi di circuiti. Pertanto, i frontend possono differire a seconda del backend con cui si aspettano di interfacciarsi.

I backend SNARK generalmente supportano i cosiddetti circuiti aritmetici, il che significa che gli input ai circuiti sono elementi di un campo finito e che le porte del circuito eseguono l'addizione e la moltiplicazione di due elementi del campo. Questi circuiti corrispondono approssimativamente a programmi per computer in linea retta (nessun ramo, istruzioni condizionali e così via) che sono di natura algebrica, ovvero il loro tipo di dati primitivo sono elementi di campo. 

La maggior parte dei backend in realtà supporta una generalizzazione di circuiti aritmetici spesso chiamati istanze Rank-1 Constraint Satisfaction (R1CS). Con la notevole eccezione di Crescita16 e i suoi predecessori, questi SNARK possono essere realizzati per supportare anche altri IR. Ad esempio, StarkWare utilizza qualcosa chiamato Algebraic Intermediate Representation (AIR), che è anche simile a una nozione chiamata Aritmetizzazione PlonKish che può essere supportato da PlonK e altri backend. La capacità di alcuni backend di supportare IR più generali può ridurre il sovraccarico dei frontend che producono tali IR. 

I backend variano anche in termini di campi finiti che supportano nativamente. Ne parlerò ulteriormente nella sezione successiva.

Vari approcci ai frontend

Alcuni programmi per computer (molto speciali) corrispondono naturalmente a circuiti aritmetici. Un esempio è il programma per computer che esegue la moltiplicazione ingenua di matrici su un campo. Ma la maggior parte dei programmi per computer non sono né lineari né algebrici. Spesso implicano istruzioni condizionali, operazioni come la divisione di numeri interi o l'aritmetica in virgola mobile che non corrispondono naturalmente all'aritmetica dei campi finiti e altro ancora. In questi casi, il sovraccarico del frontend sarà sostanziale. 

Un approccio frontend popolare è quello di produrre circuiti che essenzialmente eseguono passo dopo passo una semplice CPU, chiamata anche macchina virtuale (VM). I progettisti di frontend specificano una serie di "operazioni primitive" analoghe alle istruzioni di assemblaggio per i processori di computer reali. Gli sviluppatori che desiderano utilizzare il frontend scriveranno "programmi di controllo testimone" direttamente nel linguaggio assembly oppure in un linguaggio di livello superiore come Solidity, e faranno compilare automaticamente i loro programmi in codice assembly. 

Ad esempio, quello di StarkWare Cairo è un linguaggio assembly molto limitato in cui le istruzioni assembly consentono approssimativamente addizioni e moltiplicazioni su un campo finito, chiamate di funzioni e letture e scritture su una memoria immutabile (ovvero, write-once). La VM Cairo è un'architettura von Neumann, nel senso che i circuiti prodotti dal frontend prendono essenzialmente un programma Cairo come input pubblico e “eseguono” il programma sul testimone. Il linguaggio del Cairo è Turing Complete: nonostante il suo set di istruzioni limitato, può simulare architetture più standard, anche se farlo può essere costoso. Il frontend del Cairo avvia l'esecuzione dei programmi del Cairo T istruzioni primitive in quello che viene chiamato un "grado-2 ARIA con T righe e circa 50 colonne”. Che cosa significa esattamente questo non è importante per questo post, ma per quanto riguarda i dimostratori SNARK, ciò corrisponde a circuiti con tra 50 e 100 porte per ciascuno dei T passi della CPU del Cairo. 

RISCZero adotta un approccio simile al Cairo, ma con la macchina virtuale che è la cosiddetta Architettura RISC-V, un'architettura open source con un ricco ecosistema software che sta diventando sempre più popolare. Essendo un set di istruzioni molto semplice, progettare un frontend SNARK efficiente che lo supporti può essere relativamente trattabile (almeno rispetto ad architetture complicate come x86 o ARM). Da maggio RISC Zero sta trasformando i programmi esecuzione T istruzioni RISC-V primitive in AIR di grado 5 con 3T righe e 160 colonne. Ciò corrisponde a circuiti con almeno 500 porte per passo della CPU RISC-V. Ulteriori miglioramenti sono attesi nel prossimo futuro.

I vari progetti zkEVM (ad esempio, zkSync 2.0, Scroll, zkEVM di Polygon) considerano la macchina virtuale come (duh) la macchina virtuale di Ethereum. Il processo di trasformazione di ogni istruzione EVM in un “gadget” equivalente (cioè un circuito ottimizzato che implementa l'istruzione) è sostanzialmente più complicato rispetto alle architetture più semplici Cairo e RISC-V. Per questo e altri motivi, alcuni dei progetti zkEVM non stanno implementando direttamente il set di istruzioni EVM ma piuttosto compilando programmi Solidity di alto livello in altri linguaggi assembly prima di trasformarli in circuiti. I risultati delle prestazioni di questi progetti sono in sospeso.

Progetti di "emulatore CPU" come RISC-V e Cairo producono un unico circuito in grado di gestire tutti i programmi nel linguaggio assembly associato. Gli approcci alternativi sono “simili ad ASIC”, producendo circuiti diversi per programmi diversi. Questo approccio di tipo ASIC può produrre circuiti più piccoli per alcuni programmi, soprattutto quando l'istruzione di assembly che il programma esegue ad ogni passo temporale non dipende dall'input del programma. Ad esempio, può potenzialmente evitare completamente il sovraccarico del frontend per programmi lineari come la moltiplicazione di matrici ingenue. Ma anche l’approccio ASIC sembra molto limitato; per quanto ne so, non è noto come utilizzarlo per supportare i loop senza limiti di iterazione predeterminati. 

La componente finale del sovraccarico del frontend deriva dal fatto che tutti gli SNARK utilizzano circuiti che operano su campi finiti. La CPU del tuo laptop può moltiplicare o sommare due numeri interi con una singola istruzione macchina. Se un frontend emette un circuito su un campo con caratteristiche sufficientemente grandi, può essenzialmente simulare tale moltiplicazione o addizione tramite l'operazione di campo corrispondente. Tuttavia, l'implementazione dell'operazione sul campo su una CPU reale richiederà in genere molte istruzioni macchina (sebbene alcuni processori moderni dispongano del supporto nativo per determinati campi). 

Alcuni backend SNARK consentono scelte di campo più flessibili rispetto ad altri. Ad esempio, se il backend utilizza un gruppo crittografico G, il campo del circuito deve corrispondere al numero di elementi in G, il che può essere limitante. Inoltre, non tutti i campi supportano gli algoritmi FFT pratici. 

Esiste un solo SNARK implementato, Frenata, che supporta nativamente calcoli su campi arbitrari (sufficientemente grandi). Insieme al suo discendenti, ha le prestazioni di prova concreta più veloci conosciute anche nei campi supportati da altri SNARK, ma le sue prove sono attualmente troppo grandi per molte applicazioni blockchain. Lavoro recente cerca di migliorare la dimensione della prova, ma il prover è asintoticamente più lento e lì sembrano essere barriere alla praticità.

Alcuni progetti hanno scelto di lavorare su campi con un'aritmetica particolarmente veloce. Per esempio, Plonky2 e altri utilizzano un campo di caratteristica 2⁶⁴ - 2³² + 1 perché l'aritmetica in questo campo può essere implementata molte volte più velocemente che nei campi meno strutturati. Tuttavia, l'utilizzo di una caratteristica così piccola può portare a difficoltà nel rappresentare in modo efficiente l'aritmetica degli interi tramite operazioni sul campo (ad esempio, la moltiplicazione di due interi senza segno a 32 bit potrebbe produrre un risultato maggiore della caratteristica del campo). 

 Ma in ogni caso, affinché tutti gli SNARK più diffusi oggi raggiungano 128 bit di sicurezza (senza un aumento significativo dei costi di verifica), devono lavorare su un campo di dimensioni maggiori di 2¹²⁸. Per quanto ne so, ciò significa che ogni operazione sul campo richiederà almeno una decina di moltiplicazioni della macchina a 64 bit e un numero considerevolmente maggiore di addizioni e operazioni bit a bit. Pertanto, si dovrebbe tenere conto del sovraccarico del frontend di almeno un ordine di grandezza a causa della necessità di circuiti che operano su campi finiti. 

Per riassumere, i frontend esistenti che utilizzano l'astrazione di una macchina virtuale producono circuiti con porte da 100x a 1000x per passaggio della macchina virtuale e forse di più per macchine virtuali più complicate. Oltre a ciò, l'aritmetica dei campi finiti è almeno 10 volte più lenta delle istruzioni analoghe sui processori moderni (con possibili eccezioni se il processore ha il supporto integrato per determinati campi). Un "approccio frontend ASIC" potrebbe ridurre alcuni di questi costi generali, ma è attualmente limitato nel tipo di programmi che può supportare.

Quali sono i colli di bottiglia del backend?

Gli SNARK per la soddisfacibilità del circuito sono tipicamente progettati combinando un protocollo teoricamente sicuro delle informazioni chiamato "IOP polinomiale" con un protocollo crittografico chiamato "schema di impegno polinomiale.” Nella maggior parte dei casi, il collo di bottiglia concreto per il dimostratore è lo schema di impegno polinomiale. In particolare, questi SNARK fanno sì che il prover si impegni crittograficamente su uno o più polinomi il cui grado è (almeno) |C|, il numero di porte nel circuito C. 

A sua volta, il collo di bottiglia concreto all’interno dello schema di impegno polinomiale dipenderà dallo schema utilizzato e dalla dimensione del circuito. Ma sarà sempre una delle seguenti tre operazioni: calcolo delle FFT, esponenziazioni in un gruppo crittografico o Hashing Merkle. Il Merkle Hashing è in genere un collo di bottiglia solo se il circuito è piccolo, quindi non ne parleremo ulteriormente. 

Impegni polinomiali basati sul logaritmo discreto

Negli impegni polinomiali basati sulla durezza del problema del logaritmo discreto in un gruppo crittografico G (KZG, Bulletproofs, Dorye Impegno di Hyrax), il prover deve calcolare a Impegno del vettore Pedersen ai coefficienti del polinomio. Ciò comporta una multiesponenziazione, di dimensione pari al grado del polinomio. Negli SNARK questo grado corrisponde tipicamente alla dimensione |C| del circuito C.

Fatto ingenuamente, una multi-esponenziazione delle dimensioni |C| richiede circa 1.5·|C|·ceppo |G| ≈ 400·|C| operazioni di gruppo, dove |G| indica il numero di elementi nel gruppo G. Tuttavia, esiste un approccio, chiamato algoritmo di Pippenger, che può ridurre questo valore di un fattore approssimativamente logaritmico |C|. Per circuiti di grandi dimensioni (ad esempio, |C| ≥ 225), questo registro |C| può concretamente essere 25 o più, ovvero, per circuiti di grandi dimensioni, ci aspettiamo che l'impegno del vettore Pedersen possa essere calcolabile con poco più di 10·|C| operazioni di gruppo. Ciascuna operazione di gruppo a sua volta tende ad essere (come un campo di gioco molto approssimativo) circa 10 volte più lenta di un'operazione sul campo finito. Gli SNARK che utilizzano questi impegni polinomiali sono altrettanto costosi P come circa 100·|C| operazioni sul campo. 

Sfortunatamente, gli SNARK esistenti hanno costi aggiuntivi oltre al fattore 100x sopra indicato. Per esempio:

• spartanodeve fare il dimostratore di , che usa l'impegno polinomiale di Hyrax |C|^½ molte multi-esponenziazioni ciascuna di dimensione |C|^½, indebolendo l'accelerazione dell'algoritmo di Pippenger di un fattore pari a circa due. 
• In Crescita16, P deve lavorare su un gruppo favorevole all'accoppiamento, le cui operazioni sono in genere almeno 2 volte più lente rispetto ai gruppi che non sono amichevoli all'accoppiamento. P deve anche eseguire 3 multi-esponenziazioni anziché 1. Combinato, ciò si traduce in almeno un ulteriore rallentamento di fattore 6 rispetto a 100·|C| stima sopra. 
• Marlin ed PlonK richiedono anche accoppiamenti e i loro dimostratori si impegnano a utilizzare molto più di 3 polinomi. 
• Per qualsiasi SNARK che utilizza Bulletproofs (per esempio, Halo2, che è più o meno PlonK ma con impegni polinomiali Bulletproof anziché KZG), il dimostratore deve calcolare logaritmicamente molte multi-esponenziazioni durante la fase di "apertura" dello schema di impegno, e questo cancella in gran parte qualsiasi accelerazione di Pippenger. 

In sintesi, gli SNARK noti che utilizzano impegni vettoriali Pedersen sembrano avere un sovraccarico di backend di almeno 200x e fino a 1000x o più. 

Altri impegni polinomiali

Per gli SNARK che utilizzano altri impegni polinomiali (come VEN ed Impegno Ligero), il collo di bottiglia è che il prover deve eseguire FFT di grandi dimensioni. Ad esempio, negli AIR di grado 2 prodotti dal Cairo (con 51 colonne e T righe, una per passo della CPU Cairo), il prover distribuito da StarkWare esegue almeno 2 FFT per colonna, di lunghezza compresa tra 16 ·T ed 32 ·T. Le costanti 16 ed 32 dipendono dai parametri interni di FRI stabiliti da StarkWare e possono essere ridotti, ma al costo di maggiori costi di verifica. 

Ottimisticamente, una FFT di lunghezza 32·T ne occorrono circa 64·T·registro (32T) moltiplicazioni di campo. Ciò significa che anche per valori relativamente piccoli di T (per esempio, T ≥ 2²⁰), il numero di operazioni sul campo per colonna è almeno 64·25·T= 1600·T. Quindi il sovraccarico del backend sembra essere almeno nell'ordine delle migliaia. Inoltre, è possibile che le FFT di grandi dimensioni siano ancora più strozzate dalla larghezza di banda della memoria che dalle operazioni sul campo. 

In alcuni contesti, il sovraccarico del backend degli SNARK che eseguono FFT di grandi dimensioni può essere mitigato con una tecnica chiamata aggregazione di prove. Per i rollup, questo significherebbe questo P (il servizio di rollup) suddivide un grosso lotto di transazioni, diciamo, in 10 lotti più piccoli. Per ogni piccolo lotto i, P produce una prova SNARK πi della validità del lotto. Ma P non pubblica queste prove su Ethereum, poiché ciò comporterebbe un aumento di quasi 10 volte dei costi del gas. Invece, lo SNARK viene applicato ancora una volta, questa volta per produrre una dimostrazione π stabilendolo P conosce π₁ ...,π₁₀. Cioè, lo testimonia P afferma di sapere sono le dieci prove π₁,…,π₁₀, e il controllo diretto dei testimoni applica la procedura di verifica SNARK a ciascuna prova. Questa unica prova π è pubblicato su Ethereum. 

Negli impegni polinomiali come FRI e Ligero-commit, esiste una forte tensione tra P tempo e V costi, con parametri interni che agiscono come una manopola che può compensare l’uno con l’altro. Da π₁ ,…,π₁₀ non sono pubblicati su Ethereum, la manopola può essere regolata in modo da queste prove sono grandi e produrli è più veloce. Solo nell'applicazione finale dello SNARK, per aggregare π₁ ,…,π₁₀ in un'unica dimostrazione π, lo schema di impegno deve essere configurato per garantire una piccola prova. 

StarkWare prevede di implementare l'aggregazione delle prove imminente. Questo è anche il fulcro di progetti come Plonky2.

Quali sono gli altri colli di bottiglia per la scalabilità di SNARK?

Questo post si è concentrato sul prover tempo, ma anche altri costi del dimostratore possono costituire colli di bottiglia per la scalabilità. Ad esempio, per molti backend SNARK il prover deve memorizzare diversi elementi di campo per ogni gate Ce questo costo spaziale può essere enorme. Ad esempio, un programma ψ eseguito in un secondo su un laptop può eseguire forse un miliardo di operazioni primitive su un processore moderno. Come abbiamo visto, in generale ci si dovrebbe aspettare C richiedere ben più di 100 porte per tale operazione. Ciò significa 100 miliardi di porte che, a seconda dello SNARK, potrebbero significare decine o centinaia di terabyte di spazio per P. 

Un altro esempio: molti SNARK popolari (ad esempio, PlonK, Marlin, Crescita16) richiedono una complicata "cerimonia di installazione attendibile" per generare una "chiave di prova" strutturata che dovrà essere conservato dal prover. Per quanto ne so, il più grande cerimonia del genere ha generato una chiave di prova in grado di supportare circuiti con circa 2²⁸≈250 milioni di cancelli. La chiave di prova ha una dimensione di diverse dozzine di gigabyte. 

Nei contesti in cui è possibile l’aggregazione delle prove, questi colli di bottiglia possono essere sostanzialmente mitigati. 

Guardando al futuro: prospettive per SNARK più scalabili

Sia i costi generali di frontend che quelli di backend possono essere di tre ordini di grandezza o più. Possiamo aspettarci che questi diminuiscano sostanzialmente nel prossimo futuro? 

Penso che lo faremo, fino a un certo punto. Innanzitutto, i backend più veloci oggi (ad esempio, spartano ed Frenatae altri SNARK che combinano il protocollo di controllo della somma con impegni polinomiali) hanno dimostrazioni di grandi dimensioni, in genere radice quadrata della dimensione del circuito, quindi le persone non le utilizzano realmente. Mi aspetto che la dimensione della prova e il tempo del verificatore vengano significativamente ridotti nel prossimo futuro attraverso una composizione approfondita con SNARK a prova piccola. Similmente all'aggregazione delle prove, ciò significa che un prover genererà prima una prova SNARK π con lo SNARK “fast-prover, large-proof”, ma non inviare π a V. Piuttosto, P utilizzerebbe uno SNARK a prova piccola per produrre una dimostrazione π' che lo sa π, e invia π' a V. Ciò potrebbe ridurre di un ordine di grandezza i costi generali di backend degli SNARK che sono popolari oggi. 

In secondo luogo, l’accelerazione hardware può aiutare. Una regola generale molto approssimativa è che le GPU possono acquistare una velocità di 10 volte rispetto alle CPU e gli ASIC una velocità di 10 volte rispetto alle GPU. Tuttavia, ho tre preoccupazioni su questo fronte. In primo luogo, FFT di grandi dimensioni potrebbero subire colli di bottiglia dalla larghezza di banda della memoria piuttosto che dalle operazioni sul campo, quindi gli SNARK che eseguono tali FFT potrebbero vedere accelerazioni limitate da hardware specializzato. In secondo luogo, sebbene questo post si concentri sul collo di bottiglia dell’impegno polinomiale, molti SNARK richiedono che il dimostratore esegua altre operazioni che sono solo leggermente meno costose. Quindi, rompendo il collo di bottiglia dell'impegno polinomiale (ad esempio, velocizzare le multiesponenziazioni negli SNARK basati su log discreti) può lasciare un nuovo collo di bottiglia nell'operazione che non è molto migliore di quella vecchia. (Ad esempio, gli SNARK che includono Groth16, Marlin e PlonK hanno anche il prover che esegue FFT, oltre alle multi-esponenziazioni.) Infine, i campi e le curve ellittiche che portano agli SNARK più efficienti potrebbero continuare ad evolversi per qualche tempo e ciò potrebbe creare sfide per l’accelerazione dei prover basati su ASIC.

Dal punto di vista frontend, potremmo scoprire sempre più che l’approccio “emulatore CPU” di progetti come Cairo, RISC Zero, zkEVMs e altri in realtà si adatta abbastanza bene (in termini di prestazioni) con la complessità dei set di istruzioni della CPU. In effetti, questa è proprio la speranza di vari progetti zkEVM. Ciò può significare che, mentre il sovraccarico del frontend rimane di tre ordini di grandezza o più, i frontend riescono a supportare VM che corrispondono sempre più alle architetture della CPU reale. Una preoccupazione compensativa è che i frontend potrebbero diventare complicati e difficili da controllare, poiché proliferano gadget codificati manualmente che implementano istruzioni sempre più complicate. I metodi di verifica formale svolgeranno probabilmente un ruolo importante nell’affrontare questa preoccupazione. 

Infine, almeno nelle applicazioni blockchain, potremmo scoprire che la maggior parte dei contratti intelligenti che appaiono in natura utilizzano principalmente istruzioni semplici e compatibili con SNARK. Ciò può consentire nella pratica costi generali bassi del frontend, pur mantenendo la generalità e la migliore esperienza di sviluppo fornita con il supporto di linguaggi di programmazione di alto livello come Solidity e ricchi set di istruzioni inclusi quelli dell'EVM. 

***

Giustino Thaler is un professore associato alla Georgetown University. Prima di unirsi a Georgetown, ha trascorso due anni come ricercatore presso Yahoo Labs a New York, prima di essere ricercatore presso l'Università di New York. Istituto Simons per la teoria dell'informatica all'UC Berkeley. 

***

Ringraziamenti: sono grato a Elena Burger per aver proposto l'argomento di questo post, e a Arasu Arun, Joseph bonneaue Sam Ragsdale per commenti penetranti. Un ringraziamento speciale anche al mio editore, Tim Sullivan.

***

Le opinioni qui espresse sono quelle del personale di AH Capital Management, LLC ("a16z") citato e non sono le opinioni di a16z o delle sue affiliate. Alcune informazioni qui contenute sono state ottenute da fonti di terze parti, incluse società in portafoglio di fondi gestiti da a16z. Sebbene tratti da fonti ritenute affidabili, a16z non ha verificato in modo indipendente tali informazioni e non fornisce dichiarazioni sull'accuratezza duratura delle informazioni o sulla loro adeguatezza per una determinata situazione. Inoltre, questo contenuto può includere pubblicità di terze parti; a16z non ha esaminato tali annunci pubblicitari e non approva alcun contenuto pubblicitario in essi contenuto.

Questo contenuto viene fornito solo a scopo informativo e non deve essere considerato come consulenza legale, commerciale, di investimento o fiscale. Dovresti consultare i tuoi consulenti in merito a tali questioni. I riferimenti a qualsiasi titolo o risorsa digitale sono solo a scopo illustrativo e non costituiscono una raccomandazione di investimento o un'offerta per fornire servizi di consulenza in materia di investimenti. Inoltre, questo contenuto non è diretto né destinato all'uso da parte di investitori o potenziali investitori e non può in alcun caso essere invocato quando si decide di investire in qualsiasi fondo gestito da a16z. (Un'offerta per investire in un fondo a16z sarà fatta solo dal memorandum di collocamento privato, dal contratto di sottoscrizione e da altra documentazione pertinente di tale fondo e dovrebbe essere letta nella sua interezza.) Eventuali investimenti o società in portafoglio menzionati, citati o descritti non sono rappresentativi di tutti gli investimenti in veicoli gestiti da a16z, e non si può garantire che gli investimenti saranno redditizi o che altri investimenti effettuati in futuro avranno caratteristiche o risultati simili. Un elenco degli investimenti effettuati da fondi gestiti da Andreessen Horowitz (esclusi gli investimenti per i quali l'emittente non ha autorizzato a16z a divulgare pubblicamente e gli investimenti non annunciati in asset digitali quotati in borsa) è disponibile all'indirizzo https://a16z.com/investments /.

Grafici e grafici forniti all'interno sono esclusivamente a scopo informativo e non dovrebbero essere presi in considerazione quando si prende una decisione di investimento. I rendimenti passati non sono indicativi di risultati futuri. Il contenuto parla solo a partire dalla data indicata. Eventuali proiezioni, stime, previsioni, obiettivi, prospettive e/o opinioni espresse in questi materiali sono soggette a modifiche senza preavviso e possono differire o essere contrarie alle opinioni espresse da altri. Si prega di consultare https://a16z.com/disclosures per ulteriori informazioni importanti.