SNARK Sicurezza e prestazioni

Uno SNARK (Succinct Non-interactive Argument of Knowledge) è uno strumento crittografico che apre nuove entusiasmanti possibilità nella progettazione di sistemi, specialmente in contesti decentralizzati. Gli SNARK consentono l'elaborazione dei dati da parte di entità non attendibili, che possono quindi dimostrare che i dati sono validi e sono stati elaborati correttamente. Un modo ingenuo per dimostrarlo sarebbe quello di pubblicare i dati, consentendo a chiunque lo desideri di verificarne la validità ed elaborarli direttamente. 

Uno SNARK ottiene lo stesso effetto, ma con un costo migliores ai validatori. Ad esempio, in un rollup verificabile di secondo livello (L2), un servizio di rollup elabora le transazioni blockchain. Il servizio invia periodicamente i saldi dei conti dei suoi utenti alla blockchain di primo livello. Ogni volta che pubblica un aggiornamento dei saldi, aggiunge una prova SNARK che conosce una sequenza di transazioni valide che hanno cambiato i vecchi saldi dei conti in quelli aggiornati. In questo modo, i validatori blockchain non devono svolgere il duro lavoro di verifica della validità delle transazioni (ad esempio, verificando una firma digitale per ogni transazione) né elaborare esplicitamente le transazioni per calcolare i saldi aggiornati.  

My post precedente incentrato sulle prestazioni dei prover SNARK, il principale determinante dell'applicabilità di SNARK. Sebbene l'esecuzione di un dimostratore SNARK possa essere computazionalmente intensiva, nella misura in cui potrebbe essere impossibile generare una dimostrazione per calcoli su larga scala, la verifica SNARK è in genere molto più economica del controllo e dell'elaborazione diretta dei dati. Tuttavia, i costi di verifica SNARK variano considerevolmente. Questo post scompone questi costi e confronta le proprietà di sicurezza di diversi SNARK. 

In particolare, spiego che negli SNARK pratici con sicurezza post-quantistica plausibile (PQ-SNARK), esiste una tensione significativa tra i costi di sicurezza e di verifica. Inoltre, in alcuni casi, questa tensione si sta attualmente risolvendo a favore dei costi di verifica rispetto alla sicurezza.

Affinché gli SNARK realizzino il loro potenziale, i sistemi implementati devono essere sicuri e gli utenti devono essere sicuri della loro sicurezza. Concludo il post proponendo semplici azioni che la comunità web3 può intraprendere per aiutare a mantenere queste proprietà a lungo termine. 

Misure di sicurezza quantitative 

Uno SNARK è sicuro se è computazionalmente impossibile produrre una prova convincente di un'affermazione falsa. Ad esempio, nel contesto dei rollup L2, un utente malintenzionato che desidera rubare i miei fondi vorrebbe dimostrare una dichiarazione falsa del modulo: "Conosco una transazione firmata digitalmente che trasferisce tutti i beni di Justin sul mio conto". 

Il livello di sicurezza di uno SNARK è misurato dalla quantità di lavoro che deve essere svolto per trovare una prova convincente di una dichiarazione falsa. Analogamente ad altre primitive crittografiche come le firme digitali, il logaritmo di questa quantità di lavoro viene definito "bit di sicurezza". Ad esempio, 30 bit di sicurezza implicano che 2³⁰ ≈ 1 miliardo di "fasi di lavoro" sono necessarie per attaccare lo SNARK. Questa è intrinsecamente una misura approssimativa della sicurezza del mondo reale perché la nozione di una fase di lavoro può variare e non vengono prese in considerazione considerazioni pratiche come i requisiti di memoria o le opportunità per il parallelismo.

E quelli qualitativi

Bit di sicurezza è a quantitativo misura della sicurezza di uno SNARK. Gli SNARK differiscono anche nella loro qualitativo proprietà di sicurezza. 

Ad esempio, alcuni SNARK richiedono una cerimonia di configurazione attendibile per generare una chiave di prova strutturata. Vengono chiamati gli SNARK che non richiedono affatto una configurazione attendibile trasparente. 

Affinché uno SNARK non trasparente sia sicuro, in genere almeno un partecipante alla cerimonia deve essersi comportato onestamente, nel senso che ha prodotto e poi scartato una "botola" che, se combinata con le botole di tutti gli altri partecipanti, renderebbe facile per trovare convincenti "prove" SNARK di qualsiasi falsa affermazione. Le configurazioni attendibili lo sono essendo eseguire il con centinaia o migliaia di partecipanti per rendere questa ipotesi il più mite possibile. 

Gli SNARK differiscono anche nella loro suscettibilità agli attacchi quantistici. Nello specifico, molti SNARK (ad es. Crescita16, PlonK, Marlin, Bulletproofs, Nova) si basano sul presupposto che i logaritmi discreti siano difficili da calcolare (e in alcuni casi anche su ipotesi aggiuntive). Il calcolo dei logaritmi discreti è qualcosa che i computer quantistici sarebbero in grado di fare in modo efficiente. Quindi, questi SNARK non sono sicuri post-quantici (non PQ). 

Mentre sono in corso sforzi urgenti per passare al post-quantistico schemi di crittografia, ciò è dovuto principalmente alla necessità di mantenere segreti i messaggi crittografati per molti decenni nel futuro. Un avversario che memorizza oggi un messaggio intercettato e aspetta che arrivi un computer quantistico tra, diciamo, cinquant'anni, può usare il computer per decifrare il messaggio vecchio di cinquant'anni. La situazione con gli SNARK è molto diversa. L'uso di SNARK non PQ oggi non dovrebbe compromettere la sicurezza delle blockchain tra cinquant'anni nel futuro, anche se i computer quantistici arriveranno a quel punto. 

Impegni polinomiali

Tutti gli SNARK fanno uso di una primitiva crittografica nota come a schema di impegno polinomialee questo componente è spesso un collo di bottiglia delle prestazioni. (Per i dettagli, vedere my post precedente.) Inoltre, la trasparenza e la plausibile sicurezza post-quantistica di SNARK sono determinate esclusivamente dallo schema di impegno polinomiale che utilizza. 

Un esempio importante è il cosiddetto Impegni polinomiali KZG, che sono usati da PlonK, Marlin, e molti altri. Gli impegni KZG non sono né trasparenti né sicuri post-quantum. Altri schemi di impegno sono trasparenti ma non post-quantum, incluso Bulletproofs, Iracee Dory. 

Altri schemi ancora sono sia trasparenti che plausibilmente post-quantistici. Questi includono VEN, Leggerezza, Ligero++, Frenatae Orion. Tutti questi schemi sono basati su codici di correzione degli errori. L'hashing è l'unica primitiva crittografica che usano. Condividono inoltre la seguente proprietà: i costi di verifica (misurati dal numero di valutazioni hash e operazioni sul campo) crescono linearmente con il numero di bit di sicurezza.

In parole povere, una singola "iterazione" di questi impegni polinomiali post-quantistici raggiunge solo un piccolo numero (diciamo 2-4) bit di sicurezza. Quindi il protocollo deve essere ripetuto molte volte per "amplificare" il livello di sicurezza, con costi di verifica che crescono a ogni ripetizione. Pertanto, per controllare i costi di verifica nei PQ-SNARK (e quindi i costi del gas nelle applicazioni blockchain), i progettisti di protocolli sono incentivati ​​a mantenere basso il livello di sicurezza. 

Con raro eccezioni, questa tensione tra sicurezza concreta e costi di verifica non si verifica negli SNARK non PQ (trasparenti e non trasparenti allo stesso modo). I non-PQ-SNARK utilizzano gruppi di curve ellittiche in cui si presume che i logaritmi discreti siano difficili da calcolare e i loro livelli di sicurezza sono determinati dal gruppo utilizzato. La dimensione del gruppo di curve ellittiche appropriato, e quindi il costo di ciascuna operazione di gruppo, cresce con il livello di sicurezza desiderato. in ogni caso, il numero degli elementi di gruppo in una dimostrazione sono indipendenti dalla scelta del gruppo. 

In PQ-SNARK, non solo la dimensione delle valutazioni hash cresce linearmente con il livello di sicurezza desiderato, ma anche il numero di valutazioni incluse nella prova ed eseguite dal verificatore. 

Costi concreti del verificatore e sicurezza negli SNARK schierati

I costi concreti del verificatore e i livelli di sicurezza degli SNARK schierati variano considerevolmente. Ecco alcuni esempi illustrativi:

Costi del verificatore 

My post precedente ha citato due esempi di costi di verifica concreti: PlonK costo delle prove per 300,000 gas da verificare su Ethereum, mentre le prove di StarkWare costano circa 5 milioni di gas. Le prove di StarkWare sono trasparenti e plausibilmente post-quantiche mentre quelle di PlonK no. Tuttavia, come dettagliato di seguito, le prove di StarkWare vengono eseguite a un livello di sicurezza molto inferiore rispetto alle prove di PlonK su Ethereum.

Sicurezza concreta

L'unica curva ellittica con precompilazione di Ethereum è chiamata altbn128, quindi questa è la curva utilizzata da tutti gli SNARK non PQ distribuiti su Ethereum, incluso azteco'S e zkSync'S. Inizialmente si credeva che questa curva, e quindi anche gli SNARK distribuiti che la utilizzano, offrissero circa 128 bit di sicurezza. Ma a causa di attacchi migliorati (il cui runtime preciso è difficile da determinare), ora si ritiene che la curva offra da 100 a 110 bit di sicurezza. 

Ci sono EIP per considerazione per introdurre precompilazioni per diverse curve che si ritiene offrano ancora quasi 128 bit di sicurezza. Tali curve sono già usato negli SNARK di progetti non Ethereum tra cui ZCash, Algorand, Dfinity, Filecoin e Aleo. 

Al contrario, secondo i dati on-chain, i PQ-SNARK di StarkWare (nel suo cosiddetto sistema SHARP, abbreviazione di SHARed Prover) sono stati configurati per raggiungere 80 bit di sicurezza. Questo livello di sicurezza è valido in determinate congetture sulla solidità statistica di FRI (di cui parlerò più avanti in questo post). 

Il termine "80 bit di sicurezza" è vago in questo contesto, quindi permettetemi di spacchettarlo. In parole povere, significa che un utente malintenzionato può produrre una prova convincente di un'affermazione falsa valutando una funzione hash 2⁸⁰ times (vale a dire KECCAK-256, la funzione hash utilizzata da Ethereum). Per essere più precisi, un attaccante disposto a fare 2^k le valutazioni hash possono produrre una prova convincente con una probabilità di circa 2^k-80. Ad esempio, con 2⁷⁰ valutazioni hash, si può trovare una "prova" SNARK di un'affermazione falsa con una probabilità di circa 2 ^{all'10 ottobre} = 1/1024. 

Questa nozione è più debole di ciò che il termine "80 bit di sicurezza" significa in altri contesti. Ad esempio, una funzione hash resistente alle collisioni (CRHF) configurata su 80 bit di sicurezza produrrebbe output a 160 bit. Se la funzione hash è ben progettata, la procedura di ricerca delle collisioni più veloce sarà la Attacco di compleanno, una procedura di forza bruta che può trovare una collisione con circa 2^160/2 = 2⁸⁰ valutazioni hash. Tuttavia, con 2^k valutazioni hash, l'attacco Birthday troverà una collisione con una probabilità di solo 2^2k-160. 

Ad esempio, 2⁷⁰ le valutazioni hash produrranno una collisione con una probabilità di 2 ^{all'20 ottobre}  ≈ 1/1,000,000. Questo è di gran lunga inferiore alla probabilità di 1/1,000 che un utente malintenzionato falsifichi una prova PQ-SNARK configurata a 80 bit di sicurezza. 

Questa differenza può alterare drasticamente l'attrattiva di eseguire un attacco. Per illustrare, immagina che un utente malintenzionato abbia un budget di $ 100, che può acquistarne 2⁷⁰ valutazioni hash. E supponiamo che se l'attaccante dovesse avere successo, la vincita sarebbe di $ 200 milioni. Il valore previsto dell'attacco contro un PQ-SNARK configurato a 80 bit di sicurezza è (1/1,000) * $ 200 milioni, o $ 200, il doppio del costo. Se la probabilità di successo fosse solo 1/1,000,000, come con un CRHF, il valore atteso dell'attacco sarebbe di soli $ 200. 

Le due nozioni di "80 bit di sicurezza" differiscono notevolmente anche nella loro robustezza agli attacchi indipendenti. Ad esempio, supponiamo che 1,000 partiti indipendenti attacchino ciascuno il PQ-SNARK eseguendo 2⁷⁰ valutazioni hash. Poiché ognuno ha successo con una probabilità di circa 1/1,000, è molto probabile che almeno uno di essi abbia successo. Questo non sarebbe il caso se ognuno avesse successo con una probabilità di solo 1/1,000,000.

Ci si aspetta che i gruppi di curve ellittiche ben progettati si comportino in modo simile ai CRHF, con attacchi tipo compleanno come Algoritmo rho di Pollard essere il più conosciuto. Ciò significa che in un gruppo che offre 128 bit di sicurezza, 2^k le operazioni di gruppo dovrebbero fornire una soluzione a un'istanza del problema del logaritmo discreto con una probabilità di solo 2^2k-256. Ad esempio, 2⁷⁰ le operazioni di gruppo troverebbero un logaritmo discreto con solo una probabilità astronomicamente piccola di 2 ^{all'116 ottobre}. Inoltre, ogni operazione di gruppo è più lenta di una valutazione CRHF. 

Quante valutazioni di hash sono possibili oggi?

A gennaio 2020, il costo dell'informatica era di poco inferiore a 2⁶⁴ Le valutazioni SHA-1 utilizzando le GPU erano $45,000. Questo pone il costo di 2⁷⁰ Valutazioni SHA-1 sulle GPU a pochi milioni di dollari (forse inferiori dopo la fusione di Ethereum, poiché la transizione dal mining di proof of work dominato dalla GPU ridurrà probabilmente la domanda di GPU Computing, abbassandone il costo). 

Con i rollup di validità che già immagazzinano centinaia di milioni di dollari in fondi degli utenti, trovare una prova convincente di una dichiarazione falsa può fruttare molti milioni di dollari di profitto. La configurazione di un PQ-SNARK a 80 bit di sicurezza sotto congetture aggressive lascia meno di 10 bit di spazio di manovra tra attacchi redditizi e la presunta sicurezza di PQ-SNARK.

Come altro punto dati, l'hash rate della rete di Bitcoin è attualmente di circa 2⁶⁴  valutazioni hash al secondo, il che significa che i minatori di bitcoin nel loro insieme eseguono 2⁸⁰ Valutazioni SHA-256 ogni 18 ore. Naturalmente, questo numero strabiliante è dovuto al vasto investimento in ASIC per il mining di bitcoin. 

Assumendo sei blocchi bitcoin creati all'ora e data l'attuale ricompensa per blocco di 6.25 Bitcoin per blocco, questi 2⁸⁰ Le valutazioni SHA-256 presumibilmente costano meno di $ 22,000 * 18 * 6 * 6.25 ≈ $ 15 milioni. Altrimenti, il mining di bitcoin non sarebbe redditizio ai prezzi correnti. 

Azioni proposte per un ecosistema sano

Il punto centrale dell'utilizzo di SNARK nei rollup è ottenere la scalabilità della blockchain senza che gli utenti debbano fidarsi ciecamente del servizio di rollup. Poiché il servizio di rollup ha scritto il contratto intelligente che funge da verificatore SNARK, il pubblico deve essere in grado di ispezionare il contratto e confermare che sta effettivamente verificando le prove SNARK delle dichiarazioni appropriate. Potrebbe anche essere necessario un controllo pubblico dello smart contract per garantire che il servizio di rollup non sia in grado di censurare i propri utenti. I metodi proposti per la resistenza alla censura richiedono che il contratto intelligente del rollup consenta agli utenti di forzare il prelievo dei propri fondi se il servizio di rollup non riesce a elaborare le transazioni. 

Data la natura sofisticata di questi protocolli, questo paradigma di controllo pubblico pone alcuni oneri sugli esperti per discutere apertamente e candidamente la sicurezza dei contratti implementati. 

Ma con PQ-SNARK, può essere difficile anche per gli esperti accertare il livello di sicurezza del protocollo implementato per lo stesso motivo per cui le prestazioni di sicurezza e verificatore sono in tensione per questi SNARK: il livello di sicurezza (e i costi del verificatore) dipendono dai parametri interni del CRITICA. E almeno per StarkWare's smart contract, questi parametri, called logBlowupFactor, ​​proofOfWorkBits e n_Queries non sono specificati direttamente nel codice dello smart contract, ma piuttosto passati allo smart contract come dati pubblici. Per quanto ne so, il modo più semplice per identificare questi parametri dalle informazioni sulla catena è attraverso un processo in quattro fasi: 

1. visualizza i contratto intelligente appropriato su un block explorer come Etherscan, 
2. fare clic su un appropriata transazione di "verifica della prova"., 
3. decodificare i dati di input della transazione e
4. capire come interpretare i dati di input decodificati per apprendere i parametri chiave SNARK che insieme determinano il livello di sicurezza. 

Questo passaggio finale richiede di trovare il codice Solidity appropriato che implementa la transazione, che a sua volta può creare confusione. (Quando mi stavo preparando sondaggio colloqui sui rollup di questa estate, Etherscan è stato in grado di decodificare i dati di input rilevanti per le transazioni del verificatore SHARP come indicato al passaggio 2 sopra. Ma sembra che non funzioni più.)

Proposta 1: Controllo 

Con questo in mente, il mio primo suggerimento alla comunità web3 è di rendere molto più semplice l'esame del livello di sicurezza degli SNARK post-quantistici distribuiti. Ciò probabilmente comporta strumenti migliori per comprendere i dati sulla catena e una maggiore trasparenza da parte dei progetti stessi nel rendere noti questi parametri. 

Proposta 2: Norme più severe

80 bit di sicurezza sono troppo bassi, specialmente la versione debole in cui 2⁷⁰ le valutazioni hash sono sufficienti per attaccare con successo con una probabilità di circa 1/1000, ancora di più data la lunga storia di attacchi sorprendenti alle primitive crittografiche. Uno, menzionato sopra, è attacchi migliori a curve ellittiche compatibili con l'accoppiamento come altbn128. Un esempio più famoso è SHA-1, che è stato standardizzato a 80 bit di sicurezza ma alla fine è stato dimostrato che raggiunge solo circa 60 bit. Con questa storia in mente, i progettisti di PQ-SNARK dovrebbero lasciarsi più di 10 bit di spazio di manovra durante la configurazione del livello di sicurezza, specialmente se l'analisi della sicurezza implica forti congetture sulla sicurezza statistica di protocolli relativamente nuovi come FRI.

Anche per i PQ-SNARK è sempre possibile raggiungere livelli di sicurezza adeguati, semplicemente aumentando i costi di verifica. Ad esempio, aumentare la sicurezza del verificatore di SHARP da 80 a 128 bit (sotto congetture sulla solidità statistica di FRI) aumenterebbe i costi del gas di circa un fattore due, da poco più di 5 milioni a poco più di 10 milioni. Senza congetture su FRI, i costi del gas aumenterebbero di un altro fattore di due, a oltre 20 milioni. 

Il mio prossimo suggerimento, quindi, è che la comunità web3 dovrebbe sviluppare norme più severe intorno a livelli di sicurezza appropriati per gli SNARK distribuiti. La mia raccomandazione personale sarebbe di almeno 100 bit e almeno 128 se la sicurezza di SNARK si basa su ipotesi non standard. Non sono il primo a farlo fare una proposta del genere.

Qui, sono disposto a classificare come "presupposto standard" la sicurezza incondizionata nel modello Oracle casuale, se l'oracolo casuale nello SNARK distribuito viene istanziato con una funzione hash standard come KECCAK-256. Il modello Oracle casuale è un'impostazione idealizzata che ha lo scopo di catturare il comportamento di funzioni hash crittografiche ben progettate. Viene spesso utilizzato per analizzare la sicurezza dei PQ-SNARK. 

Un esempio di ipotesi non standard sono le congetture (descritte di seguito) riguardanti la solidità quantitativa di un protocollo come FRI, sia in un ambiente interattivo che come protocollo non interattivo nel modello Oracle casuale.

I progettisti di SNARK stanno innovando in molti modi entusiasmanti, alcuni dei quali possono spingere i limiti in termini di sicurezza, ad esempio utilizzando funzioni hash compatibili con SNARK che non sono state sottoposte a tanta crittoanalisi quanto funzioni hash più standard. Non sto chiedendo la fine di tali sforzi, tutt'altro. Ma queste primitive dovrebbero essere istanziate a livelli di sicurezza che superano gli attacchi noti e fattibili di ben oltre 10 bit. 

I rollup che utilizzano SNARK sono comunemente descritti come ereditari della sicurezza del loro L1. Ma questo è un caso difficile da realizzare se sono configurati a livelli di sicurezza molto inferiori rispetto a qualsiasi primitiva crittografica utilizzata da L1. Poiché gli SNARK vedono aumentare l'adozione, dovremmo assicurarci di implementarli in modi coerenti con il modo in cui ne parliamo. Finché gli SNARK vengono analizzati attentamente, configurati in modo appropriato e implementati correttamente, sono sicuri come qualsiasi primitiva crittografica in uso oggi. 

Una parentesi: approfondire ancora di più la sicurezza di PQ-SNARK

Gli 80 bit di sicurezza nei PQ-SNARK di StarkWare sono contabilizzati come segue. Questi PQ-SNARK fanno uso di uno schema di impegno polinomiale chiamato VENe il verificatore SHARP di StarkWare esegue FRI a 48 bit di sicurezza in base a una congettura. In parole povere, la congettura è che un semplice attacco alla solidità di FRI sia ottimale. In questo attacco, un imbroglione, con un piccolo sforzo, genera una "prova FRI" che supera i controlli scelti casualmente dal verificatore con probabilità 2 ^{all'48 ottobre}. 

StarkWare combina FRI con una tecnica chiamata "grinding". Ciò richiede che il dimostratore onesto produca una prova di lavoro a 32 bit prima di produrre una prova FRI. Il vantaggio del grinding è che aumenta drasticamente il lavoro richiesto a un imbroglione per eseguire il semplice attacco a FRI sopra menzionato, a circa 2³² valutazioni hash. 

Poiché (in attesa) 2⁴⁸ i tentativi del semplice attacco sono necessari prima che uno di essi abbia successo, la quantità totale di lavoro che il prover cheat deve fare per falsificare una prova FRI è di circa 2⁴⁸ * 2³² = 2⁸⁰ valutazioni hash.

Infine, spieghiamo come nascono i 48 bit di sicurezza per FRI. Il verificatore FRI effettua "query" al polinomio impegnato. I costi di verifica FRI crescono linearmente con il numero di query. Ad esempio, 36 query di verifica FRI sono circa 4 volte più costose di 9 query. Ma più query significano più sicurezza. Il numero di "bit di sicurezza per query" dipende da un altro parametro di FRI, chiamato code rate. 

Nello specifico, FRI utilizza qualcosa chiamato codice di velocità Reed-Solomon r, Dove r è sempre un numero strettamente compreso tra 0 e 1. I costi del prover FRI sono inversamente proporzionali a r, quindi un tasso di 1/16 porta a un prover che è circa quattro volte più lento e più ingombrante di un tasso di ¼. 

Il verificatore SHARP ha eseguito FRI con un code rate di 1/16 e con 12 query del verificatore.

StarkWare ipotizza che ogni query del verificatore FRI aggiunga log₂(1 /r) pezzetti di sicurezza. In base a questa congettura, 12 query del verificatore producono 12 * log₂(16) = 48 bit di sicurezza.

Tuttavia, le analisi attuali stabiliscono solo che ogni query del verificatore aggiunge leggermente meno di log₂(1/r^1/2) bit di sicurezza. Quindi 12 query del verificatore FRI restituiscono solo meno di 12 * log₂(4) = 24 bit di sicurezza “dimostrabile”. 

Una proposta per mitigare la tensione tra sicurezza e prestazioni

I pratici PQ-SNARK hanno costi di verifica che crescono linearmente con il numero desiderato di bit di sicurezza. Una tecnica promettente per mitigare questa tensione è la composizione SNARK, che ho descritto nel mio post precedente come un mezzo per risolvere la tensione tra i costi del dimostratore e del verificatore, ma può anche affrontare la sicurezza. 

Due esempi 

Poligono Hermez è comporre PQ-SNARK con PlonK. L'idea è che il dimostratore generi prima una prova PQ-SNARK π. Se il PQ-SNARK è configurato per avere un prover veloce e un livello di sicurezza adeguato, allora π sarà grande. Quindi il dimostratore non invia π al verificatore. Usa invece PlonK per dimostrare di conoscere π. 

Ciò significa applicare PlonK a un circuito che prende π come input e controlla che il verificatore PQ-SNARK accetti π. Poiché PQ-SNARK ha un costo di verifica polilogaritmica, PlonK viene applicato a un piccolo circuito, e quindi il prover PlonK è veloce. Poiché le prove PlonK sono piccole ed economiche da verificare, i costi di verifica sono bassi. 

Sfortunatamente, l'uso di PlonK distrugge la trasparenza e la sicurezza post-quantistica. Si può invece considerare di utilizzare lo stesso PQ-SNARK al posto di PlonK per provare la conoscenza di π (infatti il ​​PQ-SNARK usato da Polygon è autocomposto in questo modo). 

In questa seconda applicazione di PQ-SNARK, per dimostrare la conoscenza di π, il sistema può essere configurato per ottenere un'adeguata sicurezza con prove di dimensioni ragionevoli, ad esempio selezionando un code rate molto piccolo da utilizzare in FRI. Il punto chiave è che, mentre questo piccolo code rate è dannoso per il tempo del prover, la seconda applicazione di PQ-SNARK viene applicata solo a un piccolo circuito, quindi il tempo totale del prover dovrebbe essere ancora piccolo.

La nostra comprensione teorica della sicurezza degli SNARK composti lascia molto a desiderare. Tuttavia, non sono noti attacchi contro di loro che siano più veloci dell'attacco individuale di uno degli SNARK costituenti. Ad esempio, se si compone un PQ-SNARK con PlonK, non conosciamo un attacco migliore che attaccare PQ-SNARK (ovvero, trovare una prova PQ-SNARK π di un'affermazione falsa), o attaccare PlonK (ovvero, trovare una prova PlonK dell'affermazione falsa "Conosco una prova PQ-SNARK π che il verificatore avrebbe accettato.")

Comporre SNARK in questo modo è un modo sempre più popolare per migliorare le prestazioni. Spero che anche i progettisti di protocolli lo utilizzino per migliorare la sicurezza.

***

Giustino Thaler è Professore Associato alla Georgetown University. Prima di entrare a far parte di Georgetown, ha trascorso due anni come Research Scientist presso gli Yahoo Labs di New York, prima dei quali è stato Research Fellow presso il Istituto Simons per la teoria dell'informatica all'UC Berkeley. 

Editore: Tim Sullivan @tim_org

***

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.