Skip to main content

Cos'è l'EVM

Nota: Questo documento è una traduzione automatica della versione originale in inglese.

Cos'è l'EVM

L'EVM (Ethereum Virtual Machine) è il motore di computazione che alimenta Ethereum e un gran numero di altre blockchain. È l'ambiente software che esegue gli smart contract — programmi ad applicazione automatica memorizzati sulla blockchain. Quando uno sviluppatore scrive uno smart contract in Solidity (o in un altro linguaggio compatibile EVM), lo compila e lo distribuisce su una chain, è l'EVM che esegue effettivamente quel codice.

Ogni nodo di una rete compatibile EVM esegue la stessa macchina virtuale con le stesse regole. Questo è ciò che rende gli smart contract deterministici: dati lo stesso input e lo stesso stato, ogni nodo produce lo stesso output. Non c'è ambiguità, nessun problema del tipo "sulla mia macchina funziona". L'EVM garantisce che ogni partecipante della rete concordi sul risultato di ogni computazione.

In sintesi: l'EVM è il motore di esecuzione standardizzato per gli smart contract su Ethereum e sulle chain compatibili EVM. Definisce come viene eseguito il codice, come viene memorizzato lo stato e come viene consumato il gas — creando un runtime comune che funziona in modo identico su tutti i nodi.

Come funziona l'EVM

Esecuzione del bytecode

Gli smart contract non sono memorizzati on-chain come codice sorgente leggibile dall'uomo. Prima del deployment, il codice sorgente (tipicamente scritto in Solidity) viene compilato in bytecode — un insieme di istruzioni di basso livello che l'EVM comprende. Ogni istruzione è un opcode: un'operazione di base come "somma due numeri", "memorizza un valore in memoria", "carica dati dallo storage" o "trasferisci token".

Quando una transazione attiva uno smart contract, ogni nodo validante della rete:

  1. Carica il bytecode del contratto dallo stato della blockchain.
  2. Esegue gli opcode in sequenza, seguendo la specifica dell'EVM.
  3. Aggiorna lo stato della blockchain in base al risultato dell'esecuzione.
  4. Addebita gas per ogni opcode eseguito.

Poiché ogni nodo esegue lo stesso bytecode con le stesse regole, tutti arrivano allo stesso risultato. Questa esecuzione deterministica è il fondamento della computazione trustless on-chain.

Gas

Ogni opcode ha un costo in gas — un'unità di misura che rappresenta lo sforzo computazionale necessario per eseguire quell'istruzione. Il gas serve a due scopi:

  • Misurazione delle risorse — il gas previene i loop infiniti e garantisce che ogni computazione consumi una quantità limitata di risorse di rete. Un contratto che tenta di girare all'infinito esaurirà il suo gas limit e verrà annullato.
  • Meccanismo di commissioni — gli utenti pagano gas fee (denominate nel token nativo della chain) per compensare i validator che eseguono le loro transazioni. Le operazioni più complesse costano più gas.

I costi in gas sono definiti dalla specifica dell'EVM e sono gli stessi su tutte le chain compatibili EVM (sebbene il prezzo del gas nel token nativo vari da rete a rete).

Stato e storage

L'EVM mantiene uno stato globale — una mappatura dagli indirizzi (sia account utente sia account contratto) ai loro saldi correnti, al codice e allo storage. Lo storage degli smart contract è organizzato come un archivio chiave-valore: ogni contratto ha un proprio spazio di indirizzamento a 256 bit in cui può leggere e scrivere dati persistenti.

Le operazioni di storage (scrittura e lettura dello stato persistente) sono tra le operazioni EVM più costose in termini di gas, perché riguardano i dati che ogni nodo deve conservare permanentemente.

Architettura basata su stack

L'EVM è una macchina a stack: usa uno stack last-in-first-out per contenere i valori intermedi durante la computazione, anziché registri con nome. Gli opcode inseriscono valori nello stack, operano sugli elementi in cima e reinseriscono i risultati. Questo design è semplice e ben specificato, ma differisce dalle architetture basate su registri usate dalla maggior parte delle CPU tradizionali e da alcune macchine virtuali blockchain più recenti (come SBF/eBPF di Solana).

Perché l'EVM è importante

Lo standard che è diventato un ecosistema

L'importanza dell'EVM si estende ben oltre Ethereum stessa. Poiché la specifica dell'EVM è aperta e ben documentata, molte altre blockchain l'hanno adottata — eseguendo l'EVM nativamente o implementando un livello di esecuzione compatibile EVM. Questo ha creato un ecosistema condiviso:

Cosa è condiviso Cosa significa nella pratica
Linguaggio degli smart contract Gli sviluppatori scrivono Solidity una volta e distribuiscono su qualsiasi chain EVM
Strumenti di sviluppo Hardhat, Foundry, Remix e altri strumenti funzionano su tutte le chain EVM
Compatibilità dei wallet MetaMask e altri wallet EVM funzionano semplicemente aggiungendo una nuova rete
Standard di token ERC-20 (token fungibili), ERC-721 (NFT) e altri standard sono portabili tra le chain
Audit e sicurezza Gli auditor di sicurezza, gli strumenti di verifica formale e le best practice si trasferiscono tra le chain EVM
Conoscenze degli sviluppatori Uno sviluppatore che conosce Solidity e l'EVM può lavorare su Ethereum, Polygon, Avalanche, BNB Chain, Arbitrum, Base e decine di altre reti

Questa portabilità è il motivo per cui la compatibilità EVM è diventata la scelta predefinita per le nuove blockchain che vogliono attrarre rapidamente sviluppatori e applicazioni. È più economico e veloce unirsi a un ecosistema esistente che costruirne uno da zero.

Deployment multi-chain

Per i progetti — inclusi i progetti crypto legati all'AI — la compatibilità EVM significa che uno smart contract distribuito su Ethereum può essere distribuito su Polygon, sulla C-Chain di Avalanche, su Arbitrum, Base o BNB Smart Chain con modifiche minime. Questo abilita:

  • Presenza multi-chain — un progetto può distribuire lo stesso contratto di token e la stessa logica principale su più chain per raggiungere basi di utenti diverse.
  • Migrazione tra chain — se un progetto deve spostarsi su una chain con commissioni più basse o throughput più elevato, la compatibilità EVM riduce il costo della migrazione.
  • Componibilità — su qualsiasi chain EVM, i contratti possono interagire tra loro usando le stesse interfacce e gli stessi standard, abilitando la componibilità DeFi, le integrazioni di token e l'infrastruttura condivisa.

Limitazioni

L'EVM è stata progettata per l'esecuzione generica di smart contract, non per carichi di lavoro ad alta intensità di calcolo. Le limitazioni principali includono:

  • Nessuna virgola mobile nativa — l'EVM usa solo interi a 256 bit. L'aritmetica in virgola mobile (essenziale per la maggior parte delle computazioni AI/ML) deve essere emulata, il che è estremamente costoso in termini di gas.
  • Vincoli di gas — il gas limit per blocco pone un tetto alla computazione totale per blocco. Le operazioni complesse (come la moltiplicazione di matrici per l'inferenza AI) sono proibitivamente costose nell'esecuzione EVM.
  • Esecuzione sequenziale — l'EVM elabora le transazioni in sequenza all'interno di un blocco. L'esecuzione parallela, che le CPU moderne usano per le prestazioni, non è supportata nativamente (sebbene alcune chain compatibili EVM più recenti sperimentino l'esecuzione EVM parallela).
  • Costo dello storage — memorizzare grandi quantità di dati on-chain è costoso. Modelli AI, dataset e computazioni intermedie sono di gran lunga troppo grandi per l'archiviazione on-chain.

Queste limitazioni spiegano perché i progetti crypto legati all'AI eseguono tipicamente i carichi di lavoro AI off-chain e usano i contratti EVM on-chain solo per coordinamento, pagamenti, governance e registrazione dei risultati.

Dove compare nelle schede progetto DecAIHub

Nelle schede progetto DecAIHub, l'EVM compare in:

  • Type — EVM indica che il progetto opera su una chain compatibile EVM. Questo comunica al lettore che il progetto usa smart contract basati su Solidity e gli strumenti Ethereum standard.
  • Main chain — viene indicata la specifica chain compatibile EVM (Ethereum, Polygon, Avalanche, Arbitrum, Base, BNB Smart Chain, ecc.). Tutte condividono l'esecuzione EVM.
  • Token standard — le chain compatibili EVM usano gli standard di token di Ethereum. ERC-20 (token fungibili), ERC-721 (NFT) ed ERC-1155 (multi-token) sono i più comuni. Questi standard sono specifici dell'ecosistema EVM.
  • Smart contract — se gli smart contract di un progetto sono verificati su un block explorer, il lettore può ispezionarli. I contratti EVM sono scritti in Solidity (o Vyper) e compilati in bytecode EVM.

Una classificazione Type: EVM fornisce un contesto utile sugli strumenti e sull'ecosistema del progetto, ma non dice, di per sé, nulla sulla qualità dell'AI del progetto o sulla necessità del suo token.

Cosa la compatibilità EVM da sola non dimostra

  • La compatibilità EVM non dimostra capacità AI. L'EVM esegue smart contract; i modelli AI girano su GPU. Il fatto che un progetto sia su una chain EVM non dice nulla sul fatto che abbia una genuina componente AI.
  • Effettuare il deployment su una chain EVM non rende un progetto unico. Lo stesso contratto può essere distribuito su decine di chain compatibili EVM. La scelta del deployment è una decisione infrastrutturale, non un elemento differenziante.
  • Smart contract verificati non dimostrano che la componente off-chain funzioni. Un progetto può avere codice on-chain pulito e sottoposto ad audit e non avere comunque alcuna pipeline AI funzionante dietro di esso. Le componenti on-chain e off-chain devono essere valutate separatamente.
  • Gli strumenti dell'ecosistema EVM non riducono la necessità di evidenze. Avere il supporto di MetaMask, la presenza su un block explorer e token ERC-20 è infrastruttura standard — non è evidenza di tecnologia, innovazione o qualità.
  • L'esecuzione EVM non è esecuzione AI. Eseguire una rete neurale all'interno dell'EVM è proibitivamente costoso per qualsiasi modello non banale. Quando un progetto dichiara "AI on-chain" su una chain EVM, verifica esattamente cosa gira on-chain e cosa off-chain.

Da non confondere con

  • Ethereum — Ethereum è una specifica rete blockchain. L'EVM è la macchina virtuale che Ethereum (e molte altre chain) usano. "EVM" si riferisce al motore di esecuzione; "Ethereum" si riferisce alla rete, ai suoi validator e al suo stato.
  • Blockchain non-EVM — blockchain come Solana, le chain Cosmos e Bittensor usano macchine virtuali diverse (SVM, CosmWasm, runtime personalizzati). Non sono compatibili EVM, il che significa che i contratti Solidity e gli strumenti EVM non funzionano nativamente su di esse.
  • Smart contract — uno smart contract è un programma eseguito sull'EVM. L'EVM è il motore; lo smart contract è il codice che essa esegue. Gli smart contract esistono anche su chain non-EVM, con linguaggi e runtime diversi.
  • Solidity — Solidity è il linguaggio di programmazione più popolare per gli smart contract EVM, ma non è l'EVM stessa. Vyper è un altro linguaggio compatibile EVM. L'EVM esegue il bytecode compilato indipendentemente dal linguaggio sorgente che lo ha prodotto.

Domande frequenti

Cosa significa "compatibile EVM"?

Una blockchain è compatibile EVM se può eseguire bytecode EVM — la forma compilata degli smart contract Solidity — usando lo stesso insieme di opcode e le stesse regole di esecuzione di Ethereum. In pratica, questo significa che gli sviluppatori possono distribuire gli stessi contratti su più chain compatibili EVM, usare gli stessi strumenti (Hardhat, Foundry, MetaMask) e affidarsi agli stessi standard di token (ERC-20, ERC-721). Esempi di chain compatibili EVM includono Polygon, Avalanche C-Chain, BNB Smart Chain, Arbitrum e Base.

I modelli AI possono girare all'interno dell'EVM?

In teoria, qualsiasi computazione può essere espressa come opcode EVM. In pratica, eseguire modelli AI non banali all'interno dell'EVM è proibitivamente costoso. L'EVM manca del supporto nativo per la virgola mobile, ha limiti di gas rigidi per blocco e addebita costi in gas elevati per le operazioni complesse. Un singolo forward pass anche attraverso una piccola rete neurale costerebbe ordini di grandezza in più in gas di quanto qualsiasi applicazione pratica potrebbe giustificare. Ecco perché i progetti crypto legati all'AI eseguono i modelli off-chain e usano l'EVM solo per la logica di coordinamento, pagamento e verifica.

Perché così tante blockchain adottano l'EVM?

Effetti di rete. Ethereum è stata la prima grande piattaforma per smart contract, e il suo ecosistema di sviluppatori — conoscenze di Solidity, strumenti, competenze di audit, supporto dei wallet e standard di token — è cresciuto nel corso degli anni. Una nuova blockchain che adotta l'EVM ottiene immediatamente accesso a questo intero ecosistema. Gli sviluppatori non devono imparare un nuovo linguaggio, i progetti possono distribuire contratti esistenti e gli utenti possono connettersi con wallet familiari. Costruire un ecosistema concorrente da zero è molto più costoso e incerto. La compatibilità EVM è una scorciatoia pragmatica verso l'adozione.

Qual è la differenza tra compatibile EVM ed equivalente EVM?

Compatibile EVM significa che la chain può eseguire bytecode EVM e supporta gli stessi opcode, ma possono esserci differenze minori di comportamento (es. costi in gas, precompile o comportamento degli opcode nei casi limite). Equivalente EVM significa che la chain replica il comportamento dell'EVM di Ethereum a livello di opcode — ogni operazione produce lo stesso risultato che produrrebbe su Ethereum. L'equivalenza EVM è un'affermazione più forte: significa che anche contratti complessi e strumenti che dipendono dal comportamento preciso dell'EVM dovrebbero funzionare senza modifiche. Polygon zkEVM, ad esempio, punta all'equivalenza EVM.

Riferimenti esterni

  • Ethereum.org — Ethereum Virtual Machine — documentazione ufficiale della Ethereum Foundation che spiega l'architettura dell'EVM, gli opcode e il modello di esecuzione.
  • Ethereum Yellow Paper — la specifica formale del protocollo Ethereum, incluso l'insieme completo degli opcode EVM e la semantica di esecuzione.
  • EVM Codes — riferimento interattivo per gli opcode EVM con costi in gas, descrizioni e playground per testare l'esecuzione del bytecode.

Vedi anche