Il possibile futuro di Ethereum secondo Vitalik (sei): The Splurge

Nel design del protocollo Ethereum, circa la metà dei contenuti riguarda diversi tipi di miglioramenti EVM, mentre il resto è composto da vari argomenti di nicchia: questo è il significato di "Splurge".

Titolo originale: 《Possible futures of the Ethereum protocol, part 6: The Splurge》

Autore: Vitalik Buterin

Traduzione: zhouzhou, BlockBeats

Di seguito il contenuto originale (ristrutturato per una migliore comprensione):

Alcune cose sono difficili da classificare in una sola categoria; nel design del protocollo Ethereum, ci sono molti "dettagli" che sono molto importanti per il successo di Ethereum. In realtà, circa la metà dei contenuti riguarda diversi tipi di miglioramenti EVM, mentre il resto è composto da vari argomenti di nicchia: questo è il significato di "Splurge".

Roadmap 2023: Splurge

Splurge: Obiettivi chiave

• Trasformare l'EVM in uno "stato finale" ad alte prestazioni e stabile
• Introdurre l'astrazione degli account nel protocollo, consentendo a tutti gli utenti di godere di account più sicuri e convenienti
• Ottimizzare l'economia delle commissioni di transazione, migliorando la scalabilità e riducendo i rischi
• Esplorare la crittografia avanzata per migliorare significativamente Ethereum nel lungo termine

Miglioramenti EVM

Quale problema risolvono?

L'attuale EVM è difficile da analizzare staticamente, il che rende difficile creare implementazioni efficienti, verificare formalmente il codice e procedere con ulteriori espansioni. Inoltre, l'efficienza dell'EVM è bassa e molte forme di crittografia avanzata sono difficili da implementare, a meno che non siano esplicitamente supportate tramite precompilati.

Cos'è e come funziona?

Il primo passo della roadmap dei miglioramenti EVM attuali è il formato oggetto EVM (EOF), che si prevede di includere nel prossimo hard fork. EOF è una serie di EIP che specificano una nuova versione del codice EVM con molte caratteristiche uniche, la più evidente delle quali è:

• Separazione tra codice (eseguibile, ma non leggibile dall'EVM) e dati (leggibili, ma non eseguibili)
• Divieto di salti dinamici, consentendo solo salti statici
• Il codice EVM non può più osservare informazioni relative al gas
• Aggiunta di un nuovo meccanismo esplicito di subroutine

Struttura del codice EOF

Splurge: Miglioramenti EVM (continua)

I contratti legacy continueranno ad esistere e potranno essere creati, anche se alla fine potrebbero essere gradualmente deprecati (o addirittura forzati alla conversione in codice EOF). I nuovi contratti beneficeranno dell'efficienza portata da EOF—prima attraverso bytecode leggermente ridotto grazie alle subroutine, poi tramite nuove funzionalità specifiche di EOF o costi gas ridotti.

Dopo l'introduzione di EOF, ulteriori upgrade diventano più facili; attualmente, il più sviluppato è l'estensione aritmetica modulare EVM (EVM-MAX). EVM-MAX crea un insieme di nuove operazioni specifiche per il calcolo modulare e le colloca in uno spazio di memoria non accessibile da altri opcode, consentendo ottimizzazioni come la moltiplicazione di Montgomery.

Un'idea più recente è combinare EVM-MAX con la funzionalità SIMD (Single Instruction Multiple Data), un concetto presente in Ethereum da molto tempo, introdotto per la prima volta da Greg Colvin con EIP-616. SIMD può essere utilizzato per accelerare molte forme di crittografia, inclusi hash, STARKs a 32 bit e crittografia basata su reticoli; la combinazione di EVM-MAX e SIMD rende queste due estensioni orientate alle prestazioni un abbinamento naturale.

Un design approssimativo di una EIP combinata partirebbe da EIP-6690, poi:

• Consentire (i) qualsiasi numero dispari o (ii) qualsiasi potenza di 2 fino a 2768 come modulo
• Per ogni opcode EVM-MAX (addizione, sottrazione, moltiplicazione), aggiungere una versione che non utilizza più 3 immediati x, y, z, ma 7: x_start, x_skip, y_start, y_skip, z_start, z_skip, count. In Python, questi opcode funzionano come:

for i in range(count):

mem[z_start + z_skip * count] = op(

mem[x_start + x_skip * count],

mem[y_start + y_skip * count]

)

Nell'implementazione reale, questo verrà gestito in parallelo.

• Potrebbero essere aggiunti XOR, AND, OR, NOT e SHIFT (inclusi shift circolari e non), almeno per moduli potenze di 2. Aggiungere anche ISZERO (che invia l'output allo stack principale EVM), sufficiente per implementare crittografia a curve ellittiche, crittografia su piccoli campi (come Poseidon, Circle STARKs), funzioni hash tradizionali (come SHA256, KECCAK, BLAKE) e crittografia basata su reticoli. Altri upgrade EVM potrebbero essere implementati, ma finora hanno ricevuto meno attenzione.

Link alle ricerche esistenti

• EOF: 
• EVM-MAX: 
• SIMD: 

Lavoro rimanente e trade-off

Attualmente, EOF è previsto per il prossimo hard fork. Sebbene sia sempre possibile rimuoverlo all'ultimo minuto—come è successo in precedenti hard fork—farlo sarebbe una grande sfida. Rimuovere EOF significherebbe che qualsiasi futuro upgrade dell'EVM dovrebbe essere fatto senza EOF, il che è possibile ma probabilmente più difficile.

Il principale trade-off dell'EVM è tra la complessità di L1 e quella dell'infrastruttura: EOF richiede molto codice da aggiungere all'implementazione EVM, e il controllo statico del codice è relativamente complesso. Tuttavia, in cambio, possiamo semplificare i linguaggi di alto livello, l'implementazione EVM e altri benefici. Si può dire che una roadmap che dà priorità al miglioramento continuo di Ethereum L1 dovrebbe includere e basarsi su EOF.

Un lavoro importante da fare è implementare funzionalità simili a EVM-MAX + SIMD e fare benchmark sul consumo di gas di varie operazioni crittografiche.

Come interagisce con le altre parti della roadmap?

L1 che adatta la propria EVM rende più facile per L2 fare lo stesso; se non sono sincronizzati, possono sorgere incompatibilità con effetti negativi. Inoltre, EVM-MAX e SIMD possono ridurre il costo gas di molti sistemi di prova, rendendo L2 più efficienti. Rende anche più facile sostituire più precompilati con codice EVM equivalente, senza impattare troppo l'efficienza.

Astrazione degli account

Quale problema risolve?

Attualmente, le transazioni possono essere verificate solo in un modo: firma ECDSA. Inizialmente, l'astrazione degli account mirava ad andare oltre, consentendo che la logica di verifica di un account fosse qualsiasi codice EVM. Questo abilita una serie di applicazioni:

• Passaggio alla crittografia resistente ai quanti
• Rotazione delle vecchie chiavi (ampiamente raccomandata come pratica di sicurezza)
• Wallet multisig e wallet con recupero sociale
• Utilizzo di una chiave per operazioni a basso valore e di un'altra (o gruppo di chiavi) per operazioni ad alto valore

Consentire ai protocolli di privacy di funzionare senza relayer, riducendo significativamente la loro complessità ed eliminando un punto centrale di dipendenza

Dal 2015, quando fu proposta l'astrazione degli account, i suoi obiettivi si sono ampliati includendo molti "obiettivi di convenienza", ad esempio permettere a un account senza ETH ma con alcuni ERC20 di pagare il gas in ERC20. Di seguito un diagramma riassuntivo di questi obiettivi:

MPC (Multi-Party Computation) è una tecnologia con oltre 40 anni di storia, utilizzata per suddividere una chiave in più parti e conservarle su diversi dispositivi, generando firme tramite tecniche crittografiche senza combinare direttamente le parti della chiave.

EIP-7702 è una proposta che si prevede di introdurre nel prossimo hard fork; EIP-7702 nasce dalla crescente consapevolezza di fornire la convenienza dell'astrazione degli account a tutti gli utenti (compresi quelli EOA), per migliorare l'esperienza di tutti nel breve termine ed evitare la divisione in due ecosistemi.

Questo lavoro è iniziato con EIP-3074 e si è evoluto in EIP-7702. EIP-7702 offre le "funzionalità di convenienza" dell'astrazione degli account a tutti gli utenti, inclusi gli attuali EOA (account posseduti esternamente, cioè controllati da firme ECDSA).

Dal diagramma si vede che, sebbene alcune sfide (in particolare quelle di "convenienza") possano essere risolte con tecniche progressive come MPC o EIP-7702, i principali obiettivi di sicurezza che hanno motivato la proposta originale di astrazione degli account possono essere raggiunti solo tornando al problema originale: consentire al codice smart contract di controllare la verifica delle transazioni. Finora ciò non è stato realizzato a causa delle difficoltà di implementazione sicura.

Cos'è e come funziona?

Il cuore dell'astrazione degli account è semplice: consentire agli smart contract di avviare transazioni, non solo agli EOA. Tutta la complessità deriva dal farlo in modo compatibile con una rete decentralizzata e resistente agli attacchi di denial-of-service.

Una tipica sfida chiave è il problema della multi-invalidazione:

Se 1000 account hanno funzioni di verifica che dipendono da un singolo valore S, e il valore S attuale rende valide le transazioni in mempool, una singola transazione che cambia S può invalidare tutte le altre transazioni in mempool. Questo permette a un attaccante di inviare spam a basso costo, saturando le risorse dei nodi di rete.

Dopo anni di lavoro per estendere le funzionalità limitando il rischio DoS, la soluzione per una "astrazione degli account ideale" è stata trovata: ERC-4337.

ERC-4337 divide l'elaborazione delle operazioni utente in due fasi: verifica ed esecuzione. Tutte le verifiche vengono elaborate per prime, seguite da tutte le esecuzioni. Nel mempool, vengono accettate solo le operazioni utente la cui fase di verifica coinvolge solo il proprio account e non legge variabili ambientali. Questo previene attacchi di multi-invalidazione. Inoltre, vengono imposti limiti rigorosi di gas alla verifica.

ERC-4337 è stato progettato come uno standard di protocollo aggiuntivo (ERC), perché all'epoca gli sviluppatori dei client Ethereum erano concentrati sulla Merge e non avevano risorse per altre funzionalità. Per questo ERC-4337 usa oggetti chiamati UserOperation invece delle transazioni regolari. Tuttavia, recentemente si è capito che almeno parte di queste funzionalità deve essere scritta nel protocollo.

Due motivi chiave sono:

1. EntryPoint come contratto è intrinsecamente inefficiente: ogni bundle ha un overhead fisso di circa 100.000 gas, più diverse migliaia di gas per ogni operazione utente.
2. Necessità di garantire proprietà di Ethereum: ad esempio, le garanzie di inclusione create dalla inclusion list devono essere trasferite agli utenti dell'astrazione degli account.

Inoltre, ERC-4337 estende due funzionalità:

• Paymasters: consente a un account di pagare le commissioni per un altro, il che viola la regola che la verifica può accedere solo all'account mittente, quindi viene gestito in modo speciale per garantire la sicurezza.
• Aggregators: supporta l'aggregazione delle firme, come BLS o SNARK-based. Questo è necessario per la massima efficienza dei dati nei Rollup.

Link alle ricerche esistenti

• Talk sulla storia dell'astrazione degli account:
• ERC-4337:
• EIP-7702:
• Codice BLSWallet (usa aggregazione):
• EIP-7562 (astrazione degli account scritta nel protocollo):
• EIP-7701 (astrazione degli account basata su EOF scritta nel protocollo):

Lavoro rimanente e trade-off

Attualmente, il problema principale è come integrare completamente l'astrazione degli account nel protocollo; la EIP più popolare recentemente è EIP-7701, che implementa l'astrazione degli account sopra EOF. Un account può avere una parte di codice separata per la verifica; se impostata, questa viene eseguita durante la verifica delle transazioni provenienti da quell'account.

Questo approccio è interessante perché mostra chiaramente due prospettive equivalenti sull'astrazione degli account nativa:

1. Includere EIP-4337 come parte del protocollo
2. Un nuovo tipo di EOA in cui l'algoritmo di firma è l'esecuzione di codice EVM

Se iniziamo impostando limiti rigorosi alla complessità del codice eseguibile durante la verifica—non consentendo accesso a stato esterno e limiti di gas così bassi da non permettere applicazioni resistenti ai quanti o privacy—la sicurezza di questo approccio è chiara: semplicemente si sostituisce la verifica ECDSA con esecuzione di codice EVM di durata simile.

Tuttavia, col tempo dovremo allentare questi limiti, perché consentire applicazioni privacy senza relayer e la resistenza ai quanti sono molto importanti. Per questo, dobbiamo trovare modi più flessibili per gestire il rischio DoS, senza richiedere che la verifica sia estremamente semplice.

Il principale trade-off sembra essere tra "scrivere rapidamente una soluzione che soddisfa meno persone" e "aspettare più a lungo per una soluzione più ideale"; la soluzione ideale potrebbe essere un approccio ibrido. Un modo è implementare rapidamente alcuni casi d'uso e lasciare più tempo per esplorare altri. Un altro è implementare versioni più ambiziose di astrazione degli account su L2 prima. Tuttavia, ciò richiede che i team L2 abbiano fiducia nella proposta e che L1 e/o altre L2 possano adottare soluzioni compatibili in futuro.

Un altro caso d'uso da considerare sono gli account di key storage, che memorizzano lo stato dell'account su L1 o L2 dedicate, ma possono essere utilizzati su L1 e qualsiasi L2 compatibile. Farlo in modo efficace potrebbe richiedere che L2 supportino opcode come L1SLOAD o REMOTESTATICCALL, ma anche che l'implementazione dell'astrazione degli account su L2 supporti queste operazioni.

Come interagisce con le altre parti della roadmap?

Le inclusion list devono supportare le transazioni di astrazione degli account; in pratica, le esigenze delle inclusion list e di un mempool decentralizzato sono molto simili, anche se le inclusion list sono più flessibili. Inoltre, l'implementazione dell'astrazione degli account dovrebbe essere coordinata tra L1 e L2. Se in futuro ci aspettiamo che la maggior parte degli utenti utilizzi rollup di key storage, il design dell'astrazione degli account dovrebbe basarsi su questo.

Miglioramenti EIP-1559

Quale problema risolve?

EIP-1559 è stato attivato su Ethereum nel 2021, migliorando significativamente il tempo medio di inclusione dei blocchi.

Tempo di attesa

Tuttavia, l'implementazione attuale di EIP-1559 non è perfetta in diversi aspetti:

1. La formula è leggermente difettosa: non mira al 50% dei blocchi pieni, ma circa al 50-53%, a seconda della varianza (questo riguarda la "disuguaglianza media aritmetica-geometrica" in matematica).
2. Non si adatta abbastanza rapidamente in casi estremi.

La formula usata per i blobs (EIP-4844) è stata progettata per risolvere il primo problema ed è anche più semplice. Tuttavia, né EIP-1559 né EIP-4844 tentano di risolvere il secondo problema. Quindi, la situazione attuale è uno stato intermedio confuso, con due meccanismi diversi, e si ritiene che entrambi debbano essere migliorati nel tempo.

Inoltre, ci sono altre debolezze nella determinazione del prezzo delle risorse di Ethereum non legate a EIP-1559, ma che possono essere risolte modificando EIP-1559. Un problema principale è la differenza tra caso medio e caso peggiore: il prezzo delle risorse in Ethereum deve essere impostato per gestire il caso peggiore (un blocco che usa tutto il gas per una risorsa), ma l'uso medio è molto inferiore, portando a inefficienza.

Cos'è il Gas multidimensionale e come funziona?

La soluzione a questi problemi di inefficienza è il Gas multidimensionale: impostare prezzi e limiti diversi per risorse diverse. Questo concetto è tecnicamente indipendente da EIP-1559, ma la sua esistenza rende più facile implementarlo. Senza EIP-1559, impacchettare in modo ottimale un blocco con vincoli su più risorse è un problema complesso; con EIP-1559, la maggior parte dei blocchi non raggiunge il limite su nessuna risorsa, quindi un algoritmo semplice come "accetta qualsiasi transazione che paga abbastanza" è sufficiente.

Attualmente abbiamo già gas multidimensionale per esecuzione e dati; in teoria, possiamo estenderlo ad altre dimensioni: calldata, lettura/scrittura dello stato e crescita della dimensione dello stato.

EIP-7706 introduce una nuova dimensione di gas specifica per calldata. Inoltre, unifica i tre tipi di gas in un unico framework (stile EIP-4844), semplificando il meccanismo multidimensionale e risolvendo anche il difetto matematico di EIP-1559. EIP-7623 è una soluzione più precisa per il problema delle risorse caso medio/caso peggiore, limitando più rigorosamente la calldata massima senza introdurre una nuova dimensione.

Un'ulteriore direzione di ricerca è risolvere il problema della velocità di aggiornamento, cercando un algoritmo di calcolo della base fee più rapido che mantenga l'invariante chiave introdotto da EIP-4844 (cioè: nel lungo termine, l'uso medio si avvicina esattamente al valore target).

Link alle ricerche esistenti

• EIP-1559 FAQ: 
• Analisi empirica di EIP-1559: 
• Proposte di miglioramento per aggiustamenti rapidi: 
• Sezione sulle base fee in EIP-4844 FAQ: 
• EIP-7706: 
• EIP-7623: 
• Gas multidimensionale: 

Qual è il lavoro rimanente e i trade-off?

I principali trade-off del Gas multidimensionale sono due:

1. Aumenta la complessità del protocollo: introdurre il Gas multidimensionale rende il protocollo più complesso.
2. Aumenta la complessità dell'algoritmo ottimale per riempire i blocchi: per raggiungere la capacità ottimale, l'algoritmo diventa più complesso.

La complessità del protocollo è relativamente bassa per calldata, ma aumenta per le dimensioni di gas interne all'EVM (come lettura e scrittura dello storage). Il problema è che non solo gli utenti impostano limiti di gas, ma anche i contratti quando chiamano altri contratti. Attualmente, possono impostare solo limiti monodimensionali.

Una soluzione semplice è rendere il Gas multidimensionale disponibile solo all'interno di EOF, poiché EOF non consente ai contratti di impostare limiti di gas quando chiamano altri contratti. I contratti non EOF devono pagare tutti i tipi di gas per le operazioni di storage (ad esempio, se SLOAD usa lo 0,03% del limite di gas di accesso allo storage del blocco, anche gli utenti non EOF pagheranno lo 0,03% del limite di gas di esecuzione).

Ulteriori ricerche sul Gas multidimensionale aiuteranno a comprendere questi trade-off e trovare il punto di equilibrio ideale.

Come interagisce con le altre parti della roadmap?

Implementare con successo il Gas multidimensionale può ridurre notevolmente l'uso delle risorse nei "casi peggiori", riducendo la pressione per ottimizzare le prestazioni per esigenze come gli alberi binari basati su hash STARK. Impostare un obiettivo chiaro per la crescita della dimensione dello stato renderà più facile per gli sviluppatori dei client pianificare e stimare le esigenze future.

Come detto, la presenza di EOF rende più semplice implementare versioni più estreme del Gas multidimensionale, grazie alla sua caratteristica di gas non osservabile.

Funzioni di ritardo verificabili (VDFs)

Quale problema risolvono?

Attualmente, Ethereum utilizza la casualità basata su RANDAO per selezionare i proponenti; la casualità di RANDAO funziona richiedendo a ogni proponente di rivelare un segreto precedentemente impegnato, mescolando ogni segreto rivelato nella casualità.

Ogni proponente ha quindi "1 bit di potere di manipolazione": può cambiare la casualità non presentandosi (a un costo). Questo è ragionevole per la selezione dei proponenti, perché è raro rinunciare a un'opportunità per ottenerne due nuove. Ma per le applicazioni on-chain che richiedono casualità, non è ideale. Idealmente, dovremmo trovare una fonte di casualità più robusta.

Cos'è una VDF e come funziona?

Una funzione di ritardo verificabile è una funzione che può essere calcolata solo in modo sequenziale, senza accelerazione tramite parallelizzazione. Un esempio semplice è l'hash ripetuto: for i in range(10**9): x = hash(x). Il risultato, dimostrato corretto tramite SNARK, può essere usato come valore casuale.

L'idea è che l'input sia scelto in base alle informazioni disponibili al tempo T, ma l'output non sia ancora noto a T: sarà disponibile solo dopo che qualcuno avrà eseguito completamente il calcolo. Poiché chiunque può eseguire il calcolo, non c'è possibilità di nascondere il risultato, né di manipolarlo.

Il rischio principale delle VDF è l'ottimizzazione imprevista: qualcuno trova un modo per eseguire la funzione più velocemente del previsto, manipolando le informazioni rivelate al tempo T.

L'ottimizzazione imprevista può avvenire in due modi:

1. Accelerazione hardware: qualcuno costruisce un ASIC che esegue il ciclo di calcolo più velocemente dell'hardware esistente.
2. Parallelizzazione imprevista: qualcuno trova un modo per parallelizzare la funzione e accelerarla, anche se richiede 100 volte più risorse.

Il compito di creare una VDF di successo è evitare questi due problemi, mantenendo l'efficienza pratica (ad esempio, un problema dei metodi basati su hash è che dimostrare tramite SNARK in tempo reale richiede hardware pesante). L'accelerazione hardware viene solitamente gestita da un partecipante pubblico che crea e distribuisce un ASIC VDF quasi ottimale.

Link alle ricerche esistenti

• Sito di ricerca VDF: 
• Riflessioni sugli attacchi VDF in Ethereum, 2018: 
• Attacco proposto a VDF MinRoot: 

Qual è il lavoro rimanente e i trade-off?

Attualmente, nessuna costruzione VDF soddisfa pienamente tutte le esigenze dei ricercatori Ethereum. Serve ancora lavoro per trovare una funzione adatta. Se trovata, il principale trade-off è se includerla: un semplice bilanciamento tra funzionalità, complessità del protocollo e rischi di sicurezza.

Se riteniamo che una VDF sia sicura ma in realtà non lo è, la sicurezza degrada all'ipotesi RANDAO (1 bit di manipolazione per attaccante) o peggio, a seconda dell'implementazione. Quindi, anche se la VDF fallisce, il protocollo non viene compromesso, ma le applicazioni o nuove funzionalità che dipendono fortemente da essa sì.

Come interagisce con le altre parti della roadmap?

La VDF è una componente relativamente autonoma del protocollo Ethereum; oltre ad aumentare la sicurezza della selezione dei proponenti, trova applicazione anche in (i) applicazioni on-chain che richiedono casualità e (ii) mempool criptati, anche se la realizzazione di mempool criptati basati su VDF dipende da ulteriori scoperte crittografiche.

Un punto da ricordare è che, data l'incertezza dell'hardware, ci sarà un certo "margine" tra la produzione dell'output VDF e il suo utilizzo. Ciò significa che l'informazione sarà disponibile alcuni blocchi prima. Questo può essere un costo accettabile, ma va considerato nei design di finalizzazione a slot singolo o selezione dei comitati.

Offuscamento e firme one-shot: il futuro remoto della crittografia

Quale problema risolvono?

Uno degli articoli più famosi di Nick Szabo è il suo saggio del 1997 sul "God Protocol". In esso, osserva che molte applicazioni multi-parte si affidano a una "terza parte fidata" per gestire le interazioni. Secondo lui, il ruolo della crittografia è creare una terza parte fidata simulata che svolga lo stesso lavoro, senza dover effettivamente fidarsi di nessun partecipante specifico.

Finora, abbiamo realizzato solo parzialmente questo ideale. Se tutto ciò che serve è una macchina virtuale trasparente i cui dati e calcoli non possono essere spenti, censurati o manomessi, e la privacy non è un obiettivo, allora la blockchain può realizzarlo, anche se con scalabilità limitata.

Se la privacy è un obiettivo, fino a poco tempo fa potevamo solo sviluppare protocolli specifici per applicazioni particolari: firme digitali per l'autenticazione di base, ring signature e ring signature collegabili per anonimato, crittografia basata su identità per una crittografia più comoda sotto ipotesi di issuer fidati, e blind signature per Chaumian e-cash, ecc. Questo approccio richiede molto lavoro per ogni nuova applicazione.

Negli anni 2010, abbiamo intravisto per la prima volta un approccio diverso e più potente, basato sulla crittografia programmabile. Invece di creare un nuovo protocollo per ogni applicazione, possiamo usare potenti nuovi protocolli—specificamente ZK-SNARKs—per aggiungere garanzie crittografiche a qualsiasi programma.

ZK-SNARKs consentono agli utenti di dimostrare qualsiasi affermazione sui dati in loro possesso, e la prova (i) è facile da verificare e (ii) non rivela nulla oltre all'affermazione stessa. Questo è un enorme passo avanti per privacy e scalabilità; lo paragono all'impatto dei transformer nell'intelligenza artificiale. Migliaia di anni-persona di lavoro su applicazioni specifiche sono improvvisamente sostituiti da una soluzione generale in grado di affrontare problemi inaspettatamente ampi.

Tuttavia, ZK-SNARKs sono solo la prima di tre primitive generali estremamente potenti. Questi protocolli sono così potenti che mi ricordano un set di carte potentissime in Yu-Gi-Oh!, il gioco di carte e la serie TV che guardavo da bambino: le Carte degli Dei Egizi.

Le Carte degli Dei Egizi sono tre carte estremamente potenti, la cui creazione è leggendariamente pericolosa, e la loro potenza le rende proibite nei duelli. Allo stesso modo, nella crittografia abbiamo questo trio di "protocolli degli dei egizi":

Cosa sono i ZK-SNARKs e come funzionano?

I ZK-SNARKs sono uno dei tre protocolli che già possediamo, con un alto livello di maturità. Negli ultimi cinque anni, la velocità dei prover e la facilità di sviluppo sono aumentate notevolmente, rendendo i ZK-SNARKs la base delle strategie di scalabilità e privacy di Ethereum. Ma hanno una limitazione importante: bisogna conoscere i dati per poterli dimostrare. In ogni applicazione ZK-SNARK, lo stato deve avere un "proprietario" unico che deve essere presente per autorizzare letture o scritture su quello stato.

Il secondo protocollo, che non ha questa limitazione, è la crittografia completamente omomorfica (FHE), che consente di eseguire qualsiasi calcolo su dati cifrati senza vederli. Questo permette di eseguire calcoli sui dati degli utenti a loro vantaggio, mantenendo privati sia i dati che l'algoritmo.

Consente anche di estendere sistemi di voto come MACI per ottenere quasi perfette garanzie di sicurezza e privacy. Per molto tempo, la FHE è stata considerata troppo inefficiente per l'uso pratico, ma ora è finalmente abbastanza efficiente da vedere le prime applicazioni reali.

Cursive è un'applicazione che utilizza il calcolo a due parti e la FHE per la scoperta di interessi comuni in modo privato.

Tuttavia, anche la FHE ha i suoi limiti: qualsiasi tecnologia basata su FHE richiede ancora che qualcuno detenga la chiave di decrittazione. Può essere una configurazione distribuita M-of-N, o si possono usare TEEs per una seconda linea di difesa, ma rimane una limitazione.

Segue il terzo protocollo, ancora più potente della combinazione dei primi due: l'offuscamento indistinguibile (indistinguishability obfuscation). Anche se questa tecnologia è ancora lontana dalla maturità, dal 2020 abbiamo protocolli teoricamente validi basati su ipotesi di sicurezza standard, e recentemente sono iniziati i primi tentativi di implementazione.

L'offuscamento indistinguibile consente di creare un "programma cifrato" che esegue qualsiasi calcolo, nascondendo tutti i dettagli interni. Ad esempio, si può inserire una chiave privata in un programma offuscato che permette solo di firmare numeri primi, e distribuire il programma ad altri. Possono usarlo per firmare qualsiasi numero primo, ma non possono estrarre la chiave. Ma può fare molto di più: combinato con hash, può implementare qualsiasi altra primitiva crittografica e molto altro.

L'unica cosa che un programma offuscato non può fare è impedire la propria copia. Tuttavia, per questo, esistono tecnologie ancora più potenti in prospettiva, anche se richiedono che tutti abbiano un computer quantistico: le firme one-shot quantistiche.

Combinando offuscamento e firme one-shot, possiamo costruire una terza parte quasi perfettamente trustless. L'unico obiettivo che non può essere raggiunto solo con la crittografia, e che richiede ancora la blockchain, è la resistenza alla censura. Queste tecnologie possono rendere Ethereum stesso più sicuro e consentire applicazioni ancora più potenti sopra di esso.

Per capire meglio come queste primitive aggiungono capacità, prendiamo il voto come esempio chiave. Il voto è interessante perché richiede molte proprietà di sicurezza complesse, tra cui forte verificabilità e privacy. Anche se esistono protocolli di voto sicuri da decenni, possiamo complicare il problema chiedendo di progettare sistemi che gestiscano qualsiasi protocollo di voto: voto quadratico, quadratic funding con limiti di coppia, quadratic funding a cluster, ecc. In altre parole, vogliamo che il "conteggio" sia un programma arbitrario.

Per prima cosa, supponiamo che i risultati del voto siano pubblici sulla blockchain. Otteniamo verificabilità pubblica (chiunque può verificare il risultato finale, incluse le regole di conteggio e di ammissibilità) e resistenza alla censura (nessuno può impedire di votare). Ma non abbiamo privacy.

Poi aggiungiamo i ZK-SNARKs: ora abbiamo privacy, ogni voto è anonimo, e ci assicuriamo che solo gli elettori autorizzati possano votare e che ciascuno possa votare solo una volta.

Poi introduciamo MACI: i voti sono cifrati con la chiave di decrittazione di un server centrale. Il server esegue il conteggio, elimina i voti duplicati e pubblica una prova ZK-SNARK del risultato. Questo mantiene le garanzie precedenti (anche se il server bara!), ma se il server è onesto aggiunge una garanzia anti-coercizione: gli utenti non possono provare come hanno votato, nemmeno se lo vogliono. Possono dimostrare di aver votato, ma non di non aver votato per annullare il proprio voto. Questo previene tangenti e altri attacchi.

Eseguiamo il conteggio in FHE, poi una decrittazione threshold N/2-of-N. Questo porta la garanzia anti-coercizione a N/2-of-N invece che 1-of-1.

Offuschiamo il programma di conteggio, progettandolo in modo che possa rivelare il risultato solo se autorizzato, ad esempio tramite una prova di consenso blockchain, una proof-of-work o entrambe. Questo rende la garanzia anti-coercizione quasi perfetta: con consenso blockchain, serve la collusione del 51% dei validatori; con proof-of-work, anche la collusione totale rende estrarre il comportamento di un singolo elettore estremamente costoso. Possiamo anche far sì che il programma aggiunga una piccola randomizzazione al risultato finale per rendere ancora più difficile l'estrazione.

Aggiungiamo firme one-shot, una primitiva quantistica che permette di firmare solo una volta un certo tipo di informazione. Questo rende la garanzia anti-coercizione davvero perfetta.

L'offuscamento indistinguibile abilita anche altre applicazioni potenti. Ad esempio:

1. DAO, aste on-chain e altre applicazioni con stato segreto interno arbitrario.
2. Impostazioni di trusted setup veramente universali: qualcuno può creare un programma offuscato con una chiave, eseguire qualsiasi programma e fornire output, inserendo hash(key, program) come input. Chiunque può inserire il programma 3 nel proprio, combinando la chiave preimpostata e la propria, estendendo la configurazione. Questo può essere usato per generare trusted setup 1-of-N per qualsiasi protocollo.
3. Verifica ZK-SNARK con una sola firma: basta un ambiente trusted che crea un programma offuscato che firma solo se la ZK-SNARK è valida.
4. Mempool criptato: le transazioni criptate diventano facili, così che possano essere decriptate solo dopo un certo evento on-chain, anche tramite una VDF.

Con firme one-shot, possiamo proteggere la blockchain da attacchi del 51% che annullano la finalità, anche se la censura resta possibile. Primitive simili permettono la creazione di quantum money, risolvendo il problema della doppia spesa senza blockchain, anche se molte applicazioni complesse richiedono ancora la chain.

Se queste primitive diventano abbastanza efficienti, la maggior parte delle applicazioni mondiali potrà essere decentralizzata. Il principale collo di bottiglia sarà la verifica della correttezza dell'implementazione.

Ecco alcuni link a ricerche esistenti:

• Protocollo di offuscamento indistinguibile (2021): 
• Come l'offuscamento può aiutare Ethereum: 
• Prima costruzione nota di firme one-shot: 
• Tentativo di implementazione dell'offuscamento (1): 
• Tentativo di implementazione dell'offuscamento (2): 

Qual è il lavoro rimanente e i trade-off?

C'è ancora molto lavoro da fare; l'offuscamento indistinguibile è ancora molto immaturo, le implementazioni candidate sono incredibilmente lente (se non di più), troppo per l'uso pratico. L'offuscamento indistinguibile è "teoricamente" a tempo polinomiale, ma in pratica può richiedere più tempo della vita dell'universo. I protocolli recenti sono più veloci, ma ancora troppo lenti per l'uso comune: un implementatore stima un anno di runtime.

I computer quantistici nemmeno esistono: tutte le costruzioni che si vedono online sono prototipi che non fanno più di 4 bit, o non sono veri computer quantistici, anche se hanno parti quantistiche, non possono eseguire algoritmi come Shor o Grover. Recentemente ci sono segnali che i "veri" computer quantistici non sono lontani. Tuttavia, anche se apparissero presto, potrebbero volerci decenni prima che le persone possano usarli su laptop o telefoni, e prima che istituzioni potenti possano rompere la crittografia a curve ellittiche.

Per l'offuscamento indistinguibile, un trade-off chiave riguarda le ipotesi di sicurezza: esistono design più aggressivi basati su ipotesi speciali, spesso più veloci ma a volte vulnerabili. Col tempo, potremmo capire meglio i reticoli e proporre ipotesi più robuste. Tuttavia, questa strada è più rischiosa. Un approccio più conservativo è attenersi a protocolli la cui sicurezza è riducibile a ipotesi "standard", ma ciò potrebbe significare aspettare più a lungo per protocolli abbastanza veloci.

Come interagisce con le altre parti della roadmap?

Crittografia estremamente potente potrebbe cambiare radicalmente il gioco, ad esempio:

1. Se la verifica ZK-SNARK diventasse semplice quanto una firma, potremmo non aver più bisogno di protocolli di aggregazione; potremmo verificare direttamente on-chain.
2. Le firme one-shot potrebbero significare protocolli di proof-of-stake più sicuri.
3. Molti protocolli privacy complessi potrebbero essere sostituiti da una EVM privacy-preserving.
4. Il mempool criptato diventerebbe più facile da implementare.

All'inizio, i benefici saranno a livello applicativo, perché Ethereum L1 deve restare conservativo sulle ipotesi di sicurezza. Tuttavia, anche solo l'uso a livello applicativo potrebbe essere dirompente, come lo è stato l'arrivo dei ZK-SNARKs.