🇮🇹 "Zk-SNARK: configurazioni aggiustabili sulla blockchain"

:it: Traduzione italiana di “Zk-SNARKs: updatable setups on the blockchain - IOHK Blog”

Traduzione italiana a cura di Lordwotton di RIOT Stake Pools. Se apprezzi queste traduzioni, per favore valuta di supportare il mio lavoro delegando i tuoi ada a RIOT :pray: entra nel nostro gruppo Telegram


Zk-SNARK: configurazioni aggiustabili sulla blockchain

Gli Zk-SNARK si sono dimostrati un “coltellino svizzero” per blockchain e libri mastri distribuiti, con applicazioni in materia di privacy, interoperabilità e scalabilità.

img

Fin dalla loro introduzione, le prove a conoscenza zero (ZKP) sono state utilizzate per supportare potenziali applicazioni che vanno dalla verifica del calcolo in outsourcing alle credenziali anonime, in una moltitudine di contesti che richiedono un equilibrio tra privacy e integrità. Le ZKP consentono a una parte di dimostrare a un’altra che una certa affermazione o pretesa è vera, senza rivelare il contenuto di tale affermazione. L’applicazione delle ZKP in una varietà di casi d’uso sulla catena contribuisce a risolvere problemi di privacy, interoperabilità e scalabilità.

In questo post, esaminiamo i diversi tipi di ZKP e i loro casi d’uso specifici. Discutiamo inoltre di zk-SNARKs, di alcuni problemi noti nella sua applicazione e proponiamo un meccanismo di blockchain con caratteristiche di sicurezza in condizioni comparabili al protocollo blockchain. L’articolo si basa su “Mining for Privacy: How to Bootstrap a Snarky Blockchain”, scritto da Thomas Kerber, Aggelos Kiayias e Markulf Kohlweiss.

Diversi tipi di ZKP

Nel contesto della blockchain, è comune che i clienti scarichino e verifichino ogni transazione pubblicata sulla rete. Ciò significa che le dimensioni ridotte delle prove e i tempi rapidi di verifica sono importanti per l’implementazione pratica dei protocolli zero-knowledge. Esistono diversi schemi pratici tra cui scegliere, con una vasta gamma di compromessi in termini di prestazioni e presupposti crittografici:

  • Argomenti a conoscenza zero non interattivi (NIZK): è il concetto più generale. I NIZK possono essere non succinti ma, come vantaggio, possono basarsi su ipotesi crittografiche standard e spesso soddisfano forti garanzie di sicurezza.
  • Argomenti non interattivi succinti a conoscenza zero (SNARG): raggiungono la sinteticità al costo di assunzioni crittografiche più forti e spesso di garanzie di sicurezza più deboli.
  • Argomenti succinti non interattivi a conoscenza zero (SNARK o talvolta zk-SNARK): sono SNARG che sono anche prove di conoscenza e conoscenza zero. Il nome è popolare anche grazie alla poesia nonsense di Lewis Carrol “The Hunting of the Snark”.
  • Argomenti di conoscenza succinti e trasparenti (STARK): il termine trasparente si riferisce alla configurazione che richiede solo una funzione hash affidabile. Questo è vantaggioso, ma può comportare un sovraccarico di prestazioni.

Attualmente, il sistema di dimostrazione più interessante dal punto di vista del verificatore è un argomento di conoscenza succinto non interattivo (pre-elaborazione), o in breve zk-SNARK, che ha una piccola dimensione costante della prova e costi di verifica a tempo costante anche per relazioni arbitrariamente grandi. Gli zk-SNARK si sono dimostrati un “coltellino svizzero” per blockchain e libri mastri distribuiti, con applicazioni in materia di privacy, interoperabilità e scalabilità.

Casi d’uso

I casi d’uso degli zk-SNARK sono molto diversi. A volte gli SNARK vengono impiegati per migliorare le prestazioni e le proprietà di sinteticità del sistema. Altri casi d’uso impiegano gli zk-SNARK per migliorare la privacy. Alcuni casi sono misti, in cui entrambi gli aspetti giocano un ruolo.

Nel contesto della blockchain, tenendo conto delle prestazioni e della sinteticità, gli zk-SNARK possono contribuire notevolmente a casi d’uso quali:

  • Client leggeri: per migliorare l’efficienza dei parametri e la struttura complessiva delle applicazioni. Sistemi di dimostrazione efficienti (senza requisiti di conoscenza zero) svolgono un ruolo importante nel bootstrap di client leggeri. Anche i sistemi di prova ricorsivi si adattano bene a questo caso d’uso per garantire la sicurezza della ricorsione senza limiti e l’uso di funzioni esterne (ad esempio, le funzioni hash) nelle prove ricorsive.
  • Contratti intelligenti: per scaricare la possibile congestione del libro mastro dovuta all’esecuzione di contratti intelligenti pubblici. La compilazione del codice on-chain in SNARK, con tempo di verifica costante o logaritmico, può consentire validatori più complessi.
  • Prova di lavoro utile (PoUW): Gli SNARK possono essere la chiave per verificare le “computazioni utili” eseguite dai minatori, che altrimenti sarebbero costose da convalidare sulla catena.

Dal punto di vista della privacy, molte applicazioni impiegano prove a conoscenza zero per implementare soluzioni di pagamento sicure, scambio di opzioni, gestione delle identità, votazioni, aste, statistiche verificabili (una forma di oracolo blockchain) o comunicazioni anonime incentivate. I casi d’uso possono includere:

  • Contratti intelligenti privati: Gli SNARK sono parte integrante dell’attuale progettazione di smart contract privati. Due cose sono fondamentali: l’universalità, per supportare gli smart contract distribuiti dagli utenti, e la facilità di compilazione. L’espressività dei contratti intelligenti può essere eliminata per ridurre lo spazio del problema, ad esempio vietando i loop non limitati e la ricorsione, in modo da non rendere necessaria la composizione ricorsiva degli SNARK. Fondamentalmente, un sottoinsieme di un linguaggio contrattuale di alto livello può essere compilato in un circuito SNARK.
  • Pagamenti privati: i beni possono essere visti come una particolare forma di rivendicazione di identità che include la modellazione della scarsità. Una proposta di pagamenti privati può anche supportare token multi-asset e non fungibili, e collegare questi token agli smart contract.
  • Gestione dell’identità: Nel contesto delle credenziali verificabili, gli emittenti possono affermare affermazioni sui soggetti generando oggetti crittografici (credenziali). I soggetti presentano poi le loro credenziali ad altri utenti che agiscono come verificatori. I verificatori sono quindi in grado di convalidare le affermazioni dell’emittente sul soggetto che presenta la credenziale.
  • Votazione e tesoreria: Le prove ZK possono essere utilizzate nelle votazioni di tesoreria. Un sistema di tesoreria per il protocollo delle criptovalute, ad esempio, fornisce uno schema di voto che preserva la privacy, in cui le schede degli elettori sono crittografate e successivamente conteggiate utilizzando calcoli omomorfi. Le prove ZK nella tesoreria sono protocolli Sigma non interattivi basati su DLP utilizzati per dimostrare la correttezza dei messaggi crittografati in varie fasi del protocollo (ad esempio, che la scheda crittografata dell’elettore contiene una scheda composta correttamente).

I casi d’uso misti includono:

  • Oracoli della blockchain: Gli SNARK possono ridurre i costi di verifica quando si aggregano dati da più fonti e possono ridurre le dimensioni dei dati pubblicati sulla catena includendo solo il valore aggregato e la prova, invece di tutti i punti dati. Per ottenere queste due proprietà, le parti devono essere in grado di dimostrare in modo sintetico la conoscenza delle firme su un certo numero di punti di dati e la rispettiva media/varianza.
  • Sidechains: una catena in una configurazione di chain pegging può agire come un client leggero verso l’altra catena, verificando le transazioni cross-chain sull’altra catena senza dover verificare l’intera catena. La differenza è che questo pegging è spesso mantenuto a lungo termine e quindi le prove possono essere fornite regolarmente e in modo “aggiornabile”. Per ulteriori informazioni, consultare Proof of stake Sidechains.

Problemi noti

La conoscenza zero non interattiva richiede una certa casualità condivisa o una stringa di riferimento comune. Per molti sistemi succinti, è necessaria una proprietà più forte:

Non solo è necessario un valore casuale condiviso, ma deve aderire a una struttura specifica. Una stringa di riferimento strutturata (SRS) consiste tipicamente in elementi di gruppo correlati, ovvero: gxi per tutti gli i∈𝕫n.

Il modo più ovvio di campionare una tale stringa di riferimento da una casualità pubblica rivela gli esponenti utilizzati, e la conoscenza di questi valori infrange la solidità del sistema di prova stesso. A peggiorare le cose, la sicurezza di questi sistemi si basa tipicamente (tra le altre cose) sulla conoscenza delle ipotesi sugli esponenti, che affermano che per creare elementi di gruppo correlati in questo modo è necessario conoscere gli esponenti sottostanti; di conseguenza, qualsiasi campionatore SRS dovrà “conoscere” gli esponenti utilizzati ed essere fidato di cancellarli, diventando, di fatto, un singolo punto di fallimento per il sistema sottostante.

Il calcolo multipartitico sicuro (MPC) può essere utilizzato, ed è stato utilizzato, per ridurre la fiducia riposta in tale processo di impostazione. Tuttavia, la selezione dei partecipanti al calcolo sicuro e la verifica della generazione dell’SRS da parte del protocollo MPC mantengono un elemento di centralizzazione. L’uso dell’MPC rimane un elemento controverso nella configurazione di un sistema decentralizzato che richiede gli SNARK.

Risolvere i problemi di privacy con la generazione sicura di SRS

Una stringa di riferimento strutturata aggiornabile (uSRS) può essere inizializzata in modo sicuro utilizzando un libro mastro distribuito, richiedendo ai creatori di blocchi di eseguire aggiornamenti su una uSRS in evoluzione durante un periodo iniziale di impostazione. Dopo aver atteso l’accordo sulla uSRS finale, questa può essere utilizzata in modo sicuro.

La prova di ciò si basa sulle modalità di funzionamento di base dei ledger di tipo Nakamoto: diversi utenti possono estendere una catena di blocchi se sono in grado di soddisfare una certa condizione, associata a un tipo di durezza che garantisce che gli aggressori siano limitati nel numero di estensioni che possono eseguire. Data una struttura di questo tipo, associamo un aggiornamento uSRS a ciascun blocco prima di un tempo 𝛿1. Questo tempo è scelto in modo tale che le proprietà di sicurezza del libro mastro garantiscano che almeno uno dei blocchi sia onesto in ogni catena competitiva a questo punto.

Questo può essere costruito da una funzionalità del libro mastro con uno stato di leadership aggiuntivo, derivato dalle informazioni che i minatori incorporano nei loro blocchi per codificare gli aggiornamenti di uSRS. Questa soluzione è sufficientemente generale da consentire anche altri usi. L’idea di base è dimostrare che un libro mastro che esegue aggiornamenti uSRS nel suo stato di leadership è equivalente a quello che non lo fa, ma è accompagnato da un uSRS sicuro. Dopo il tempo 𝛿1, gli utenti attendono un ulteriore periodo di tempo 𝛿2 fino a quando il prefisso comune assicura che tutte le parti concordino sulla stringa di riferimento.

Astrazione del ledger proposta

La nostra costruzione della funzionalità di stringa di riferimento strutturata aggiornabile si basa sulle proprietà del prefisso comune, della qualità della catena e della crescita della catena definite nell’analisi della dorsale Bitcoin da Garay et al. per gli algoritmi di consenso in stile Nakamoto:

  • Prefisso comune. Date le catene attuali 𝛱1 e 𝛱2 di due parti, e rimuovendo k blocchi dalla prima, è un prefisso della seconda: 𝛱1⌊k ≺𝛱2.
  • Qualità della catena esistenziale. Per la catena corrente di un partito 𝛱, ogni blocco consecutivo l di questa catena includerà almeno un blocco creato da un partito onesto.
  • Crescita della catena. Se la catena di un partito è di lunghezza c, allora s slot temporali dopo, sarà almeno di lunghezza c+𝛾.

Costruzione decentralizzata di uSRS

La costruzione da noi proposta, descritta nel documento Mining for Privacy, è semplice: ogni catena è associata a uno specifico uSRS e quando un miner estende una catena, esegue anche un aggiornamento dell’uSRS. Alla genesi della catena può essere utilizzata una casualità nota (o addirittura nessuna casualità). Il principio alla base di questo progetto è semplice: l’aggiornabilità di uSRS garantisce che se un singolo aggiornamento viene eseguito onestamente (sia utilizzando una vera casualità, sia cancellando questa casualità dopo l’aggiornamento), l’uSRS risultante può essere utilizzato in modo sicuro. Per garantirlo ci affidiamo alla proprietà di qualità della catena esistenziale: una volta che sono stati generati l blocchi, almeno uno di questi deve essere creato da un minatore onesto, e quindi dopo l blocchi, l’uSRS di una catena è sicuro.

Tuttavia, non è sufficiente sapere che la stringa di riferimento di una particolare catena è sicura: per la maggior parte delle applicazioni pratiche, vogliamo che tutti gli utenti concordino sulla stringa di riferimento. Ciò è garantito dalla proprietà del prefisso comune, che garantisce che per qualsiasi catena lunga l+k blocchi, tutti gli altri utenti avranno la stessa stringa di riferimento generata da questa catena - a patto che gli utenti smettano di aggiornare dopo l blocchi!

Infine, la crescita della catena garantisce che l’evento a cui siamo interessati - quando tutti sono d’accordo sulla stringa di riferimento - alla fine si verificherà. Garantisce che alla fine gli utenti avranno una catena di lunghezza l+k. In particolare, poiché ogni s unità di tempo vengono generati blocchi, l’evento si verificherà al più tardi al tempo ⌈(l+k)/s⌉.

Tutto ciò va bene in astratto, ma lascia delle questioni di praticità: queste analisi astratte presuppongono che gli aggiornamenti possano essere creati con costi minimi o nulli e che non influiscano sulla procedura di mining standard. Tuttavia, questo non è del tutto vero per il mining di proof-of-work:

  1. Gli aggiornamenti sono relativamente costosi e richiedono dai 5 ai 10 minuti per essere calcolati, a seconda delle dimensioni dell’uSRS interessato.
  2. È possibile imbrogliare sugli aggiornamenti, eseguendoli più velocemente ma senza aggiungere la sicurezza della stringa di riferimento.

La combinazione di questi fattori rappresenta una sfida, soprattutto nel contesto proof-of-work, dove l’aggiornamento deve essere eseguito prima che un minatore possa iniziare a estrarre un blocco. Questo ritarda i minatori non imbroglioni, mentre le loro controparti imbroglione stanno già estraendo! Di conseguenza, la difficoltà di estrazione (corrispondente al tempo previsto tra un blocco e l’altro) non dovrebbe essere troppo bassa, in quanto più è bassa, maggiori sono i vantaggi per i minatori che imbrogliano. D’altra parte, una difficoltà elevata porta naturalmente a un tempo più lungo per raggiungere il consenso. Questo compromesso è illustrato nella Figura 1.

Se la difficoltà è calibrata in modo appropriato, un’analisi di simulazione mostra che questo effetto non danneggia la sicurezza complessiva. A seconda della probabilità di fallimento (є) che siamo disposti a tollerare e della frazione della potenza di estrazione di un attaccante (а) da cui vogliamo proteggerci, l’uSRS può essere generato in modo sicuro con la procedura in poche ore o in diversi mesi in uno scenario più pessimistico, come illustrato nella Figura 1.

img

Figura 1. Il tempo necessario per garantire almeno un aggiornamento onesto, in funzione del tempo del blocco target.

Fonte: “Mining for Privacy: How to Bootstrap a Snarky Blockchain”.

Un problema simile si presenta quando si considera il comportamento razionale: i minatori che cercano solo il profitto cercheranno di imbrogliare sugli aggiornamenti, non per cattiveria, ma semplicemente perché in questo modo possono produrre blocchi più velocemente. Questo problema può essere aggirato premiando ulteriormente il comportamento corretto: si può chiedere a un campione di minatori di fornire la casualità dei loro aggiornamenti e di dimostrare che è stata campionata in modo appropriato (ad esempio, utilizzando una funzione hash). Se sono in grado di farlo, possono ottenere una ricompensa aggiuntiva, che compensa l’eventuale perdita subita per non aver imbrogliato.

In sintesi, l’applicabilità di zk-SNARK è di grande utilità per diversi casi d’uso sulla catena, risolvendo problemi di privacy, interoperabilità e scalabilità. Sebbene l’impostazione fiduciaria, richiesta per molti zk-SNARK, sembri in contrasto con la natura decentralizzata dei ledger distribuiti, può essere eseguita in modo completamente decentralizzato per gli SNARK con stringhe di riferimento aggiornabili. Sebbene in linea di principio sia possibile utilizzare anche SNARK trasparenti come Halo, le tecniche sopra descritte consentono a SNARK come Plonk (che possono essere più efficienti a seconda delle circostanze), che si basano su stringhe di riferimento aggiornabili, di essere utilizzati in modo sicuro anche per applicazioni on-chain: non è più vero che le configurazioni degli SNARK sono troppo opache per essere affidabili, se mai lo sono state.