Una panoramica sulle ZK-EVM

Una ZK-EVM è una Virtual Machine che integra la tecnologia ZK-SNARK per creare prove crittografiche di esecuzione su transazioni simili a Ethereum, sia per integrarla nella catena Ethereum stessa sia per costruire ZK-rollup più scalabili.

Guardo alle ZK-EVM dall’esterno, ma è sempre così intrigante capire quale sarà il prossimo progresso tecnologico. Inoltre, mi sono innamorato della tecnologia ZK-SNARK nel lontano 2017 quando facevo ricerche su Zcash.

Vitalik Buterin ha appena fatto un riassunto meraviglioso, ma anche piuttosto tecnico, di tutti i tipi di ZK-EVM che vengono costruiti. Penso che sia abbastanza convinto che Ethereum alla fine scalera con gli ZK-rollup, che consentono tempi di prova più rapidi e una migliore privacy su tutta la linea.

Tipo 1: Completamente equivalenti a Ethereum

Pro: Sono progettati per verificare i blocchi EVM e supportare lo stesso execution layer (ma non il consensus layer, quindi probabilmente non funzioneranno immediatamente con la beacon chain). Gli strumenti possono essere riutilizzati, così come l’infrastruttura per costruire rollup più integrati con l’L1: ad esempio, i client possono verificare sia l’L1 che il rollup senza ulteriori modifiche.

Contro: poiché Ethereum non è stato progettato per provare i blocchi ZK, una prova può richiedere molte ore per essere calcolata. Le soluzioni possono essere trovate nella parallelizzazione o in macchine ASIC dedicate.

Tipo 2: Completamente equivalenti a EVM

Pro: quasi uguali a Ethereum, ma hanno differenze nella struttura dei blocchi, nell’albero di stato e in altri aspetti. I client lavoreranno anche con i rollup con alcune modifiche. Le modifiche alla funzione di hash e all’albero di Merkle, così come la rimozione della verifica dell’hash esterno, possono migliorare il tempo di prova.

Contro: Poiché ci sono differenze nell’albero di stato, le app che verificano le prove di Merkle dei blocchi storici potrebbero non funzionare (alcuni bridge funzionano in questo modo). Inoltre, è ancora necessario accedere e verificare la memoria e potrebbero esserci problemi di interpretazione (il compilatore che deve leggere un’istruzione in più blocchi invece di uno).

Tipo 2.5: Equivalenti a EVM, ad eccezione dei costi del gas

Pro: Aumenta i costi del gas per alcune operazioni che sono molto difficili da provare con ZK. Ciò aiuta a ridurre il tempo del prover nel caso peggiore, consentendo di allocare una larghezza di banda maggiore.

Contro: Alcune applicazioni potrebbero non funzionare e alcune funzioni potrebbero non essere più possibili (più operazioni in una transazione sono negli stessi blocchi, meno gas può occupare ciascuna di esse, poiché il limite di gas per blocco è fisso).

Tipo 3: Quasi equivalenti a EVM

Pro: L’obiettivo è raggiungere la ZK-EVM al Layer 1, sacrificando alcune funzionalità come precompilazioni, modifiche alla memoria e interpretazione del codice del contratto.

Contro: Alcune applicazioni dovranno essere ricostruite poiché dipendono da precompilazioni e altre modifiche.

Il Tipo 3 è inteso come una fase di transizione verso la ZK-EVM di Tipo 1.

Tipo 4: Equivalente al linguaggio di alto livello

Un sistema di Tipo 4 funziona prendendo il codice sorgente dello smart contract scritto in un linguaggio di alto livello (ad esempio Solidity, Vyper o qualche intermedio a cui entrambi compilano) e compilando quello in un linguaggio progettato esplicitamente per essere ZK-SNARK-friendly.

Contro: è più semplice perché evita tutte le difficoltà nel provare l’execution layer dell’EVM

Pro: poiché sarà un byte code diverso, alcune funzioni (come CREATE2) non funzioneranno come previsto e l’infrastruttura di debug dovrebbe essere ricostruita per il nuovo linguaggio/bytecode.

Per come la vedo io, questo è uno sforzo di quasi un decennio per rendere Ethereum più scalabile utilizzando le prove ZK. Tutti i progetti attualmente in sviluppo sono lontani anni dall’essere in produzione e se il Merge di Ethereum ci ha insegnato qualcosa, è che le cose accadranno a passi piccolissimi e possono sorgere molti errori.

Molto probabilmente, ogni tipo di EVM raggiungerà il Tipo 1 (tranne alcuni Tipo 4 che avranno casi d’uso specifici per rimanere come Tipo 4) e attraverserà tutti i tipi. Come dice Vitalik, clienti diversi potrebbero utilizzare implementazioni e metodi di prova diversi, ma non sono sicuro se ciò significherà che la rete diventi più decentralizzata: molto probabilmente diventerà più sparsa e non perfettamente ridondante, poiché l’execution layer non viene elaborato allo stesso modo.

Tuttavia, l’EVM è la Virtual Machine più flessibile e robusta che conosca, quindi l’aggiunta di prove ZK avrà effetti sull’intero ecosistema EVM per gli anni a venire.

Buy me a coffee @ home