Perché la ZkEVM esegue il codice di Ethereum ma lo dimostra con prove a conoscenza zero

La Ethereum Virtual Machine (ETH), nata nel 2015, è stata progettata per eseguire smart contract — non per generare prove crittografiche.
Le prove a conoscenza zero, al contrario, sono state pensate per verificare calcoli in modo economico e privato, senza alcun concetto di opcode.

Per anni, i due mondi sono sembrati intrinsecamente incompatibili.

Poi gli ingegneri hanno trovato il modo di fonderli, dando vita a una delle infrastrutture tecniche più sofisticate dell’intero ecosistema crypto.

La ZkEVM — acronimo di Zero-Knowledge Ethereum Virtual Machine — è il tentativo di eseguire smart contract compatibili con Ethereum e dimostrare poi, tramite prove ZK, che l’esecuzione è avvenuta correttamente, senza chiedere agli sviluppatori di riscrivere una sola riga di codice.

In teoria suona semplice. In pratica ha significato risolvere problemi che hanno bloccato l’intero settore per almeno cinque anni.

TL;DR

Una ZkEVM esegue smart contract compatibili con Ethereum e genera una prova a conoscenza zero che l’esecuzione è corretta, permettendo di regolare rapidamente e a basso costo le transazioni sul mainnet di Ethereum.

Più una ZkEVM è difficile da costruire, maggiore è la sua compatibilità con gli strumenti Ethereum esistenti: questo compromesso è al centro di ogni scelta progettuale.

Gli utenti beneficiano della sicurezza di Ethereum senza pagare le fee del mainnet, mentre gli sviluppatori possono distribuire contratti Solidity esistenti con modifiche minime o nulle.

Cosa fanno davvero le prove a conoscenza zero

Prima di parlare di EVM, serve chiarire che cos’è — e cosa non è — una prova a conoscenza zero.
Una prova ZK è un metodo crittografico che consente a una parte, il prover, di convincere un’altra parte, il verifier, che un’affermazione è vera, senza rivelare i dati sottostanti che la rendono tale.

L’esempio classico è dimostrare di conoscere una password senza inviare la password.
Nel contesto blockchain, l’affermazione da dimostrare è quasi sempre computazionale:
«Ho eseguito questo programma su questo input, ho ottenuto questo output, e l’ho fatto in modo corretto».

Il verificatore, in questo caso uno smart contract su Ethereum Layer 1, controlla la prova in millisecondi, invece di rieseguire tutte le transazioni.

Le prove a conoscenza zero permettono a un network di Layer 2 di aggregare migliaia di transazioni, generare un’unica prova compatta della loro validità e pubblicare solo quella su Ethereum, abbattendo drasticamente il costo per utente.

Due famiglie di sistemi di prova dominano oggi il panorama ZkEVM.
I SNARK (Succinct Non-interactive ARguments of Knowledge) producono prove piccole e veloci da verificare, ma richiedono una cerimonia di trusted setup.
Gli STARK (Scalable Transparent ARguments of Knowledge) non necessitano di trusted setup e sono resistenti ai computer quantistici, ma generano prove più grandi.
La maggior parte dei team ZkEVM ha per ora convergito sui sistemi basati su SNARK, perché il costo di verifica sul mainnet Ethereum è un vincolo rigido.

Da leggere anche: Trump Media cancella l’accordo Cronos da 6,42 miliardi con Crypto.com

Perché è così difficile dimostrare l’EVM

La Ethereum Virtual Machine è un ambiente di esecuzione basato su stack, con oltre 140 opcode, un sistema di gas, una struttura di memoria complessa e una serie di edge case accumulati in un decennio di utilizzo reale.
Ogni opcode — dal semplice ADD alle precompile crittografiche come ECRECOVER — deve essere rappresentabile come vincolo aritmetico affinché un sistema ZK possa “ragionare” sulla sua esecuzione.

Il problema è che i sistemi di prova ZK parlano un linguaggio matematico estremamente ristretto.
Operano nativamente su campi finiti ed equazioni polinomiali. L’EVM è stata progettata ignorando completamente questi vincoli.
Opcode come KECCAK256 (la funzione di hashing di Ethereum) sono quasi il peggior caso possibile per i circuiti ZK, perché coinvolgono operazioni bitwise che si traducono in insiemi di vincoli enormi e costosi.

Questo mismatch ha generato quello che i ricercatori hanno battezzato “problema di incompatibilità con l’EVM”.
Si poteva costruire un rollup ZK veloce ed economico, ma in grado di eseguire solo programmi scritti appositamente per ambienti ZK‑friendly. Oppure si poteva puntare al pieno supporto EVM, ma con tempi e costi di generazione della prova talmente elevati da vanificare i benefici.
La sfida ingegneristica della ZkEVM è proprio comprimere questo trade-off.

Generare una prova ZK per un singolo hash KECCAK256 può richiedere milioni di vincoli aritmetici.
Un blocco Ethereum tipico contiene migliaia di hash: per questo, nelle prime implementazioni, la generazione delle prove ZkEVM richiedeva ore e oggi necessita ancora di hardware specializzato.

Da leggere anche: Arthur Hayes prevede un rally di Bitcoin se la Fed sblocca i 1.373 miliardi di Treasury in yen del Giappone

Le quattro tipologie di ZkEVM e cosa implicano

Non tutte le ZkEVM sono uguali. Nel 2022 il ricercatore di Ethereum Vitalik Buterin ha proposto una tassonomia, oggi di riferimento, che suddivide le implementazioni in quattro tipologie a seconda del grado di compatibilità con lo stack Ethereum esistente. Capire queste categorie è il modo più rapido per valutare qualsiasi progetto ZkEVM.

Tipo 1: piena equivalenza Ethereum.
Dimostra esattamente la stessa transizione di stato, la stessa struttura di blocco, le stesse funzioni di hash, senza alcuna modifica.
I client Ethereum esistenti possono sincronizzarla nativamente e tutti gli strumenti continuano a funzionare out‑of‑the‑box.
Il prezzo da pagare è una generazione delle prove estremamente lenta e costosa. Nessuna ZkEVM in produzione opera oggi a livello Tipo 1, anche se alcuni team la stanno inseguendo.

Tipo 2: equivalenza EVM.
Cambia alcune strutture dati interne — ad esempio sostituendo KECCAK con un hash più ZK‑friendly nel state trie — ma mantiene la piena compatibilità con il bytecode EVM.
Gli smart contract si comportano in modo identico. Gli sviluppatori non notano differenze.
La generazione delle prove è più rapida rispetto al Tipo 1, ma ancora pesante. Scroll e le prime versioni di Polygon zkEVM si collocano in quest’area.

Tipo 3: ulteriori modifiche che rompono un piccolo sottoinsieme di funzionalità marginali, come alcune precompile.
La stragrande maggioranza dei contratti esistenti continua a funzionare.
Il costo di generazione delle prove scende in modo significativo.
La maggior parte delle ZkEVM lanciate commercialmente tra il 2023 e il 2024 si è posizionata tra Tipo 2 e Tipo 3 nelle release iniziali.

Tipo 4: il codice sorgente in Solidity o Vyper viene compilato verso una VM custom ZK‑friendly, invece di dimostrare direttamente il bytecode EVM.
È l’opzione più veloce ed economica, ma può introdurre sottili differenze di comportamento e impedire alcuni trucchi di basso livello tipici dell’EVM.
zkSync Era adotta questo modello con un compilatore custom basato su LLVM.

Questa classificazione è cruciale per i builder.
Un progetto che vuole migrare un protocollo DeFi già collaudato dal mainnet Ethereum cercherà Tipo 2 o Tipo 3 per avere massima parità di comportamento.
Chi costruisce da zero può accettare un Tipo 4 in cambio di costi di prova più bassi e finalità più rapida.

Da leggere anche: Anthropic blocca 191 megawatt di energia in Texas da un miner di Bitcoin

Come una ZkEVM elabora concretamente una transazione

Seguire il percorso di una singola transazione dall’inizio alla fine aiuta a rendere tangibile l’architettura.
Quando un utente invia una transazione a una rete ZkEVM, la sequenza è la seguente.

Per prima cosa, la transazione raggiunge un sequencer, il nodo che ordina e raccoglie le transazioni in batch.
Il sequencer esegue le transazioni, aggiorna lo stato del Layer 2 e fornisce all’utente una “soft confirmation” immediata.
A questo punto il wallet dell’utente mostra il nuovo saldo, ma la transazione non è ancora finalizzata crittograficamente su Ethereum.

In un secondo momento, il batch di transazioni viene inoltrato a un prover, software (o hardware) specializzato che esegue l’algoritmo ZK.
Il prover prende lo stato pre‑esecuzione, tutte le transazioni e lo stato post‑esecuzione e genera una prova di validità che certifica la correttezza della transizione di stato.
Questo passaggio è computazionalmente intenso e può richiedere da pochi secondi a diversi minuti, a seconda del sistema.

Terzo passo: la prova e una piccola quantità di dati compressi sulle transazioni vengono inviati a uno smart contract su Ethereum, il verifier contract.

Questo contratto verifica la prova in una singola chiamata on‑chain, con un costo di gas fisso indipendente dal numero di transazioni nel batch.
Una volta verificata, la radice di stato del Layer 2 è finalizzata su Ethereum ed è considerata sicura quanto una transazione sul mainnet.

Da leggere anche: Un ETF su XRP compare nella disclosure del fondo crypto da 111.000 dollari della National Bank of Canada

ZkEVM modulare e interoperabilità cross‑chain

Il design originario della ZkEVM assumeva un unico livello di settlement: Ethereum.
Tutto veniva provato e regolato sul mainnet.
Un’architettura più recente, la ZkEVM modulare, separa invece livello di esecuzione, livello di prova e livello di settlement, permettendo di combinarli in modo indipendente.

È qui che entrano in gioco progetti come Prom.

Prom si definisce una ZkEVM modulare di Layer 2 che abilita interoperabilità sia con chain EVM sia con chain non‑EVM.
Invece di limitarsi a provare l’esecuzione e a fare settlement su Ethereum, invia le prove in parallelo a più chain, creando un ponte matematico tra ecosistemi che prima non avevano collegamenti trustless.

L’approccio modulare è importante perché rimuove l’assunto che Ethereum sia l’unica superficie legittima di settlement.

Una prova ZkEVM è, in ultima analisi, pura matematica.
Se la Chain A e la Chain B dispongono entrambe di un verifier contract capace di controllare quella matematica, una singola prova può finalizzare la stessa transizione di stato su entrambe le chain contemporaneamente.
È così che le prove ZK diventano un primitivo universale di interoperabilità, oltre che una tecnologia di scalabilità.

Le architetture ZkEVM modulari disaccoppiano esecuzione e settlement: la stessa prova di validità può essere verificata su Ethereum, su una chain non‑EVM o su entrambe, creando una fonte condivisa di verità crittografica tra ecosistemi altrimenti incompatibili.

Da leggere anche: TRON ha processato 2,1 trilioni di dollari in USDT, ma la sua liquidità DeFi si è ridotta 1,9%](https://yellow.com/news/tron-cleared-2-1-trillion-usdt)

ZkEVM contro Optimistic Rollup, confronto diretto

Il paragone tra ZkEVM e optimistic rollup torna di continuo, e non è un caso: attaccano lo stesso problema con filosofie diametralmente opposte.

Gli optimistic rollup assumono per default che le transazioni siano valide e le verificano solo se qualcuno presenta una “fraud proof” entro una finestra di contestazione (in genere sette giorni). Questo li rende più economici da gestire e più semplici da implementare, ma implica che i prelievi verso la mainnet Ethereum richiedano una settimana, a meno di usare bridge di liquidità. Arbitrum e Optimism sono oggi le reti optimistic rollup dominanti.

Gli ZkEVM rollup, invece, non assumono nulla: ogni batch è considerato invalido finché la prova non dimostra il contrario. Il costo computazionale lato prover è più elevato, ma i prelievi possono essere finalizzati su Ethereum in poche ore anziché giorni, senza dipendere da “watcher” onesti che intercettino eventuali frodi.

Per l’utente finale, le differenze pratiche si riassumono così:

Velocità di prelievo: ZkEVM vince nettamente: la finalità basata su prove richiede ore, contro i sette giorni dei prelievi nativi su optimistic rollup.
Costo delle transazioni: Oggi gli optimistic rollup sono spesso più economici, perché la generazione delle prove aggiunge un overhead. Ma il divario si sta riducendo, grazie a hardware e algoritmi di proving sempre più efficienti.
Modello di sicurezza: ZkEVM offre garanzie di validità crittografiche. Gli optimistic rollup si basano su una sicurezza economica via fraud proof: è un modello robusto, ma non equivalente alla dimostrazione matematica.
Compatibilità con l’EVM: Le ZkEVM moderne (Type 2/3) hanno sostanzialmente colmato il gap e supportano ormai quasi tutto l’ecosistema di tool Ethereum, facendo venir meno quello che era uno dei principali vantaggi degli optimistic rollup.
Rischio di liveness: I sistemi ZkEVM possono bloccarsi se il prover smette di funzionare. Gli optimistic rollup continuano a processare transazioni finché il sequencer rimane operativo.

Nessun approccio è universalmente superiore. Le applicazioni ad alto volume che privilegiano il costo minimo e possono tollerare una settimana di attesa per i prelievi tendono verso gli optimistic rollup. I progetti che richiedono finalità rapida, settlement cross-chain o una prova matematica di correttezza preferiscono gli ZkEVM.

Chi sta davvero beneficiando degli ZkEVM oggi

ZkEVM non è una tecnologia futuribile sulla carta: più reti sono già operative, con valore reale bloccato e utenti che pagano commissioni reali. Ma resta fondamentale capire chi trae il massimo beneficio da ciascun livello dello stack.

I protocolli DeFi che migrano dalla mainnet Ethereum beneficiano di semantica di esecuzione quasi identica (Type 2/3) e di costi gas drasticamente inferiori. Un protocollo che sulla mainnet escludeva l’utenza retail con fee da 30 dollari a swap può offrire transazioni sotto il centesimo su una ZkEVM senza dover riscrivere gli smart contract.

I bridge e le applicazioni cross-chain sfruttano architetture ZkEVM modulari che pubblicano prove su più chain. Invece di doversi fidare di un bridge multisig – storicamente la categoria più colpita dagli hack in crypto – gli utenti possono affidarsi a una prova matematica verificata on-chain.

Le imprese e le istituzioni che sviluppano applicazioni permissioned o semi-permissioned ottengono un ambiente di esecuzione collaudato con auditabilità crittografica. Ogni transizione di stato è dimostrabilmente corretta, un aspetto chiave per compliance e contabilità.

Gli sviluppatori che lanciano progetti oggi dovrebbero capire bene il trade-off tra Type 4 e Type 2 prima di scegliere la rete. Se si scrive nuovo codice Solidity e si vuole massimizzare la velocità di proving e minimizzare le fee, una rete Type 4 può essere ideale. Se invece si migra un protocollo esistente e non ci si può permettere differenze di comportamento, una Type 2 o Type 3 è la scelta più prudente.

Per l’utente comune, ZkEVM si presenta semplicemente come una chain Ethereum-compatibile, economica e veloce, dove il wallet che usa già funziona e i token esistenti possono essere bridgeati. Tutta la complessità crittografica sottostante resta invisibile, esattamente come dovrebbe essere in un’infrastruttura ben progettata.

Conclusioni

ZkEVM rappresenta probabilmente il problema di convergenza più complesso nella crittografia applicata: prendere una virtual machine progettata senza alcuna struttura matematica e costringerla a parlare il linguaggio delle zero-knowledge proof.

I team che ci sono riusciti hanno passato anni a confrontarsi con incompatibilità tra funzioni di hash, esplosione dei vincoli e hardware per i prover che, quando venivano scritti i paper teorici, semplicemente non esisteva.

Il settore è ancora in fase di rapida evoluzione. I tempi di generazione delle prove continuano ad accorciarsi. Reti di prover decentralizzati stanno entrando in produzione. La piena equivalenza Type 1 con Ethereum rimane l’obiettivo, e diversi team stanno riducendo il gap a vista d’occhio.

Per chiunque sviluppi o investa nell’ecosistema Ethereum, capire davvero come funziona ZkEVM – al di là degli slogan di marketing – è la base su cui poggia ogni decisione successiva.

Da leggere dopo: La spinta da 500 miliardi di dollari di Nvidia per l’AI mette sotto osservazione i token crypto legati al calcolo