Un’impronta di 32 byte tiene allineati migliaia di nodi Ethereum
Nella prima settimana di novembre 2026 Base, BNB Chain e la rete Tempo hanno distribuito aggiornamenti ai propri operatori di nodi. Un bug in staking means depositing a proof of stake coin with a protocol that stakes it for you and issues a transferable token (such as Lido stETH or rETH) representing the deposit plus rewards, which you can use or sell while the coins stay staked.">Reth, un execution client sviluppato da Paradigm, poteva far calcolare a un nodo una state root sbagliata. Le correzioni sono uscite tra blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">il 4 e il 6 novembre e non sono state segnalate perdite di fondi, exploit o interruzioni, come racconta il nostro articolo su il bug della state root di Reth e le patch dei layer 2. L’episodio è un buon punto di ingresso per capire come funziona la Ethereum Virtual Machine, perché Reth è uno dei programmi che la implementano. La correzione, la pull request 28264 di Reth, è stata integrata il 3 novembre con il titolo «fix(trie): tighten iterator seek boundary».
La state root è un unico numero di 32 byte. Ogni intestazione di blocco Ethereum ne contiene una. Riassume ogni saldo, ogni frammento di codice dei contratti e ogni slot di storage così come si trovano dopo l’esecuzione delle transazioni del blocco. Migliaia di computer, che fanno girare cinque client principali scritti in quattro linguaggi di programmazione, ricalcolano quel numero ciascuno per conto proprio. Un nodo che arriva a un valore diverso non è più d’accordo con la catena. Le regole che tutti devono riprodurre, fino all’ultimo bit, sono quelle della Ethereum Virtual Machine (EVM), la «macchina virtuale di Ethereum».
Quello che segue parte dai dati, cioè lo stato globale e il modo in cui un blocco si impegna su di esso, poi apre la macchina: il bytecode eseguito un opcode alla volta su una pila di parole a 256 bit, le chiamate tra contratti, il percorso di una transazione dalla firma alla ricevuta, i client che eseguono il tutto e i cambiamenti in arrivo. Riprende da dove si era fermata la nostra lezione sulla storia di Ethereum e sul white paper. Non serve Solidity: restiamo al livello dei byte.
Lo stato globale: un registro di conti e ciò che ciascuno certifica
Quattro campi per conto, e che cosa ne fa la macchina
Ogni conto Ethereum ha quattro campi: un nonce, un saldo in wei, un hash del codice e una radice dello storage. I conti a controllo esterno (EOA) sono governati da una chiave privata; i conti contratto sono governati dal proprio codice e non possono avviare una transazione da soli. La nostra guida a modello UTXO e modello a conti tratta già questi campi, il nonce e il peso dello storage dei contratti, quindi qui guardiamo solo che cosa fa l’EVM con essi.
I conti si trovano tramite un indirizzo di 20 byte. Per un EOA l’indirizzo è composto dagli ultimi 20 byte dell’hash Keccak-256 della chiave pubblica, secondo la documentazione di ethereum.org sui conti. Per un contratto l’indirizzo viene derivato al momento della creazione, come descritto più avanti. L’hash del codice punta al bytecode, e la macchina non ha alcuna istruzione per riscrivere il codice conservato a un indirizzo dopo il deploy. La radice dello storage è a sua volta la radice di un secondo albero, che contiene lo storage di quel solo contratto.
La documentazione di Ethereum scrive l’intero sistema come una funzione, Y(S, T) = S’: uno stato precedente più una transazione valida dà un nuovo stato. Ogni nodo applica la stessa funzione allo stesso input e deve arrivare allo stesso risultato. Tutto il resto di questa lezione è un dettaglio di quella funzione.
Perché lo stato è un trie e non una tabella
Una tabella di conti sarebbe facile da memorizzare e impossibile da verificare senza scaricarla per intero. Ethereum conserva invece lo stato in quello che ethereum.org chiama Merkle Patricia Trie modificato: un albero con fino a 16 rami per nodo, in cui il percorso verso una foglia è scritto dalla chiave e ogni nodo è identificato dall’hash del proprio contenuto. Se cambia un saldo, cambiano gli hash lungo il percorso dalla foglia fino alla cima, fino alla state root nell’intestazione del blocco.
Il vantaggio sono le prove. Un nodo può consegnare a un estraneo la breve lista di nodi dell’albero tra un conto e la radice, e chiunque abbia l’intestazione del blocco può verificare che il saldo sia quello dichiarato. Una richiesta eth_getProof a un nodo Ethereum pubblico il 10 novembre 2026 ha restituito, per un normale indirizzo, una prova del conto di nove nodi. Lo storage di ogni contratto forma un proprio trie dello stesso tipo, ed è per questo che il saldo di un token è alla fine una foglia nell’albero dello storage del contratto del token. I numeri tornano: la proposta EIP-8037 indica che il database di stato di Geth era di circa 390 GiB a gennaio 2026.
Albero binario, albero Verkle o nessuno dei due: il prossimo albero di stato è ancora una bozza
Il trie esadecimale ha un costo. Le prove sono lunghe, perché ogni livello può portare fino a 15 hash fratelli, e Keccak è lento da dimostrare nei circuiti a conoscenza zero. Per anni il piano ufficiale è stato un albero Verkle, e la pagina della roadmap su ethereum.org lo descrive ancora così. Da gennaio 2025 c’è un progetto concorrente: EIP-7864, «Ethereum state using a unified binary tree», scritto da Vitalik Buterin, Guillaume Ballet, Dankrad Feist e altri.
EIP-7864 farebbe partire un nuovo albero binario che contiene insieme dati dei conti, codice e storage, mentre il trie esistente viene congelato e poi migrato da una proposta separata. I suoi autori sostengono che un albero basato solo su hash dia prove più piccole, si presti meglio alle prove a conoscenza zero ed eviti la crittografia a curve ellittiche su cui si basano gli alberi Verkle, che un giorno i computer quantistici potrebbero rompere. La funzione di hash non è stata scelta: la bozza usa BLAKE3 per i test e indica Keccak e Poseidon2 come candidati. Al 10 novembre 2026 l’EIP è ancora una bozza (Draft) e nessun aggiornamento con un nome programma modifiche all’albero di stato.
Come funziona la Ethereum Virtual Machine: una macchina a pila di parole a 256 bit
Il bytecode: che cos’è davvero un contratto on-chain
On-chain, uno smart contract non è altro che una stringa di byte memorizzata a un indirizzo. L’indirizzo del token USDC su Ethereum, 0xA0b8…eB48, conteneva 2.186 byte di codice il 10 novembre 2026. Dall’aggiornamento Spurious Dragon del 22 novembre 2016 (blocco 2.675.000), EIP-170 limita il codice distribuito a 24.576 byte. EIP-7954, previsto per l’aggiornamento Glamsterdam (stato Last Call, scadenza della revisione 1 novembre 2026), alzerebbe quel tetto a 64 KiB, cioè 65.536 byte, e il limite del codice di inizializzazione da 48 KiB a 128 KiB.
Ogni istruzione, o opcode, è un byte. 0x01 è ADD, 0x55 è SSTORE, 0x00 è STOP. Alcuni opcode portano dati in linea: PUSH1 (0x60) è seguito da un byte da mettere sulla pila, e così via fino a PUSH32, che ne porta 32. Un contratto scritto in Solidity o Vyper viene compilato in questo formato, come mostra dal lato dello sviluppatore la nostra guida per imparare Solidity.
Quando una transazione chiama un contratto, i suoi dati di input (calldata) di solito iniziano con un selettore di funzione di 4 byte, i primi quattro byte dell’hash Keccak-256 della firma della funzione. 0xa9059cbb, per esempio, è transfer(address,uint256), la funzione dietro la maggior parte dei trasferimenti di token. Le prime istruzioni del contratto leggono quei quattro byte e saltano al pezzo di codice corrispondente. Non esiste un altro meccanismo di smistamento.
La pila: 1.024 posizioni da 256 bit
È una macchina a pila con una profondità di 1.024 elementi, e ogni elemento è una parola di 256 bit. Ethereum.org spiega la dimensione della parola con la crittografia che la catena usa ogni giorno: gli hash Keccak-256 e le chiavi secp256k1 stanno entrambi in 256 bit. La maggior parte degli opcode prende gli input dalla cima della pila e vi rimette il risultato. ADD estrae due parole e inserisce la loro somma, modulo 2^256.
La macchina non ha registri. Le istruzioni DUP e SWAP raggiungono solo i 16 elementi più in alto, un limite che EIP-8024 (previsto per Glamsterdam) toglierebbe con tre nuove istruzioni, SWAPN, DUPN ed EXCHANGE. Inserire un 1.025º elemento, o estrarre da una pila vuota, interrompe l’esecuzione in corso con un errore.
Cinque posti dove tenere i dati, cinque durate
Il codice di un contratto lavora con diverse aree di dati. Si distinguono per quanto durano e per quanto costano, e questa differenza plasma il modo in cui si scrive ogni contratto.
| Area di dati | Che cosa contiene | Durata | Costo tipico (gas) | Chi può scriverla |
|---|---|---|---|---|
| Pila (stack) | Fino a 1.024 parole da 256 bit | Un frame di chiamata | Da 2 a 3 per opcode semplice | Il codice in esecuzione |
| Memoria | Un array di byte che cresce man mano che si usa | Un frame di chiamata | 3 per accesso a una parola, più un costo di espansione crescente | Il codice in esecuzione |
| Storage | Coppie chiave-valore di parole a 256 bit, per contratto | Permanente, parte dello stato globale | 2.100 per una prima lettura (a freddo), 100 a caldo; 22.100 per riempire uno slot vuoto a freddo | Solo il codice che gira nel contesto di quel contratto |
| Storage transitorio | Coppie chiave-valore per contratto | Una transazione | 100 per TLOAD o TSTORE | Solo il codice che gira nel contesto di quel contratto |
| Calldata | Byte di input della chiamata, in sola lettura | Un frame di chiamata | Pagato dal mittente come parte del gas intrinseco | Il chiamante |
Lo storage transitorio è l’area più recente. È arrivato con EIP-1153 nell’aggiornamento Dencun del 13 marzo 2024 (sul lato dell’esecuzione, Cancun) e aggiunge due opcode, TLOAD (0x5c) e TSTORE (0x5d). L’EIP ne fissa la durata in modo netto: «All values in transient storage are discarded at the end of the transaction» (testo originale in inglese). Costa una frazione dello storage e si usa per i blocchi anti-rientranza (reentrancy lock) o per passare dati tra contratti nella stessa transazione. Due aree in sola lettura completano il quadro: i dati restituiti dall’ultima chiamata e il codice del contratto stesso.
Un programma di nove byte, eseguito a mano
Il modo più rapido per vedere la macchina all’opera è far girare un programma minuscolo. I nove byte 0x600260030160005500 sommano 2 e 3 e salvano il risultato nello slot 0 dello storage. Chiunque può riprodurre l’esecuzione con il metodo eth_call di un nodo pubblico e uno state override che mette questo codice a un indirizzo vuoto.
60 02 PUSH1 0x02
60 03 PUSH1 0x03
01 ADD
60 00 PUSH1 0x00
55 SSTORE
00 STOP| Passo | Opcode | Pila dopo (cima per prima) | Gas addebitato | Gas di esecuzione finora |
|---|---|---|---|---|
| 1 | PUSH1 0x02 | [2] | 3 | 3 |
| 2 | PUSH1 0x03 | [3, 2] | 3 | 6 |
| 3 | ADD | [5] | 3 | 9 |
| 4 | PUSH1 0x00 | [0, 5] | 3 | 12 |
| 5 | SSTORE (chiave 0 in cima, valore 5) | [] | 22.100 | 22.112 |
| 6 | STOP | [] | 0 | 22.112 |
SSTORE prende la chiave dalla cima della pila e il valore subito sotto, quindi l’ordine dei push conta. Quattro istruzioni economiche costano 12 gas in tutto; l’unica scrittura nello storage costa 22.100, perché lo slot viene toccato per la prima volta nella transazione (2.100) e passa da zero a un valore diverso da zero (20.000). Aggiungendo i 21.000 gas che ogni transazione paga prima che giri qualunque codice, il conto è di 43.112 gas. Il 10 novembre 2026 un nodo pubblico ha accettato la chiamata con un limite di 43.112 gas e l’ha rifiutata con 43.111, rispondendo «out of gas».
Altri cinque micro-programmi, eseguiti allo stesso modo nello stesso giorno, danno il prezzo delle altre aree di dati. Le cifre qui sotto sono gas di esecuzione, dopo la base di 21.000.
| Programma | Che cosa fa | Gas di esecuzione misurato (10 nov 2026) |
|---|---|---|
| 0x60005400 | Legge una volta lo slot 0 dello storage (a freddo) | 2.103 |
| 0x600054506000545000 | Legge due volte lo slot 0 | 2.210 (2.100 a freddo, poi 100 a caldo) |
| 0x600160005d00 | Scrive 1 nello slot transitorio 0 | 106 |
| 0x60005c5000 | Legge lo slot transitorio 0 | 105 |
| 0x600160005200 | Scrive una parola in memoria | 12 (9 per gli opcode, 3 per far crescere la memoria di una parola) |
Confrontate le righe: riempire uno slot di storage vuoto è costato 22.100 gas, una scrittura transitoria 100, un rapporto di 221 a 1. Chi progetta i contratti spende molto impegno per evitare SSTORE.
Perché ogni istruzione ha un prezzo
Il gas è prima un contatore e poi una commissione
Il white paper del 2014 era franco sul rischio di una catena programmabile: l’EVM è Turing-completa e, nelle sue parole, «this means that EVM code can encode any computation that can be conceivably carried out, including infinite loops» (testo originale in inglese). Nessuno può prevedere in generale se un programma si fermerà (il problema dell’arresto), quindi Ethereum non ci prova. Ogni transazione fissa un limite di gas; la macchina detrae il prezzo di ogni opcode prima di eseguirlo; quando il contatore scenderebbe sotto zero, l’esecuzione si ferma con un errore di gas esaurito, le modifiche di stato di quella chiamata vengono annullate e il gas resta consumato. Un ciclo che non finisce mai, semplicemente, resta senza gas. La lezione di storia racconta come è nata l’idea; il meccanismo qui sopra è ciò che è diventata.
I prezzi fanno parte del protocollo. Il codice sorgente di Go Ethereum elenca i valori in vigore, e gli EIP spiegano da dove vengono.
| Operazione | Gas (regole della mainnet in vigore il 10 novembre 2026) | Fonte |
|---|---|---|
| ADD, PUSH1, MSTORE (base) | 3 ciascuno | Riferimento degli opcode di ethereum.org |
| KECCAK256 | 30 più 6 per ogni parola di 32 byte sottoposta a hash | Parametri di protocollo di Go Ethereum |
| Da LOG0 a LOG4 | 375, più 375 per topic, più 8 per byte di dati | Parametri di protocollo di Go Ethereum |
| SLOAD | 2.100 a freddo, 100 a caldo | EIP-2929 |
| Accesso a un conto (CALL, BALANCE, EXTCODESIZE…) | 2.600 a freddo, 100 a caldo | EIP-2929 |
| CALL con invio di ETH | 9.000 in più; 25.000 in più se il conto destinatario non esiste | Parametri di protocollo di Go Ethereum |
| CREATE, CREATE2 | 32.000, più 200 per byte di codice distribuito e 2 per ogni parola di 32 byte di codice di inizializzazione; CREATE2 aggiunge 6 per parola per fare l’hash di quel codice | Parametri di protocollo di Go Ethereum |
| Base della transazione (intrinseco) | 21.000 | Parametri di protocollo di Go Ethereum |
I prezzi a freddo e a caldo hanno una storia. EIP-2929, attivato con l’aggiornamento Berlin il 15 aprile 2021 (blocco 12.244.000), ha alzato il costo del primo accesso a un conto o a uno slot di storage in una transazione, dopo gli attacchi di denial of service del 2016. L’EIP cita riesecuzioni in cui le transazioni d’attacco impiegavano da 20 a 80 secondi, contro pochi millisecondi per una transazione media, e dice che alzare quei prezzi di un fattore circa 3 porta il caso peggiore a circa 7-27 secondi. Una scansione delle transazioni sulla testnet Goerli, aggiunge, ha indicato un aumento medio dei costi in gas di circa il 2,36%.
Quello che l’utente paga alla fine è il gas usato moltiplicato per un prezzo per unità di gas, composto da una commissione base che viene bruciata e da una mancia al validatore. Quel meccanismo, EIP-1559 e la storia delle commissioni appartengono alla nostra prossima lezione su gas ed EIP-1559. Per la macchina contano due limiti. Il blocco 26.383.691, prodotto alle 09:43 UTC del 10 novembre 2026, aveva un limite di gas di 60 milioni, il valore predefinito adottato dai team dei client con Fusaka (EIP-7935), e ne ha usati 33,57 milioni, con una commissione base di 0,0549 gwei. Dall’aggiornamento Fusaka del 3 dicembre 2025, EIP-7825 limita inoltre ogni singola transazione a 16.777.216 gas (2^24).
Deterministica per costruzione
Perché migliaia di nodi concordino su una sola state root, ogni istruzione deve dare lo stesso risultato ovunque. L’EVM non ha quindi numeri in virgola mobile, né accesso alla rete, né file system, né altro orologio che il timestamp del blocco corrente. Tutto ciò che un contratto sa del mondo esterno, un prezzo per esempio, deve essere scritto on-chain da una transazione, ed è il lavoro di un oracolo.
Questa rigidità è ciò che permette a codebase indipendenti, in Go, C#, Java e Rust, di eseguire gli stessi blocchi e arrivare alla stessa state root. I client si verificano anche con suite di test condivise: ethereum.org osserva che ogni execution client da essa elencato supera i test dei client. Chi invia una transazione tramite un nodo pubblico non ha modo di sapere quale client l’abbia eseguita, e non ne ha bisogno.
Quando i contratti chiamano altri contratti
CALL, STATICCALL e DELEGATECALL decidono quale storage cambia
Un contratto può chiamarne un altro nel mezzo della propria esecuzione. Ogni chiamata apre un nuovo frame con pila e memoria proprie. Tre opcode fanno la maggior parte del lavoro, e la scelta tra di essi decide quali dati può toccare il codice chiamato.
| Opcode (byte) | Codice che gira | Storage che cambia | Mittente visto dal chiamato | Può modificare lo stato? |
|---|---|---|---|---|
| CALL (0xF1) | Quello del bersaglio | Quello del bersaglio | Il contratto chiamante | Sì, e può inviare ETH |
| STATICCALL (0xFA) | Quello del bersaglio | Nessuno | Il contratto chiamante | No: ogni tentativo di modificare lo stato fallisce |
| DELEGATECALL (0xF4) | Quello del bersaglio | Quello del chiamante | Il chiamante del chiamante | Sì, ma nello storage del chiamante |
Il sorgente di Go Ethereum descrive DELEGATECALL come l’esecuzione del codice del bersaglio «with the caller as context», con il mittente impostato su «the caller of the caller» (testo originale in inglese). In parole semplici, il contratto chiamante prende in prestito la logica di un altro contratto e la fa girare sui propri dati.
È così che funzionano i proxy aggiornabili. I 2.186 byte all’indirizzo di USDC sono un proxy: custodiscono i saldi nel proprio storage e inoltrano ogni chiamata con DELEGATECALL a un contratto di logica separato, il cui indirizzo è conservato in uno degli slot di storage del proxy. Il 10 novembre 2026 quello slot puntava a 0x4350…02dd. Sostituite l’indirizzo nello slot e lo stesso token esegue codice nuovo. Chi detiene quel potere è una questione di governance che rimandiamo alla lezione successiva sui contratti aggiornabili e le chiavi di amministrazione.
Una chiamata che invia ETH passa anche un sussidio di 2.300 gas al destinatario, troppo poco per scrivere nello storage. I vecchi contratti che si basano proprio su quella cifra sono uno dei motivi per cui la revisione dei prezzi di Glamsterdam, descritta più avanti, è delicata.
CREATE e CREATE2: dove nascono i nuovi contratti
I nuovi contratti nascono dall’esecuzione di un codice di inizializzazione, il cui output diventa il codice memorizzato. Con CREATE (0xF0) il nuovo indirizzo deriva dall’indirizzo del creatore e dal suo nonce. Con CREATE2 (0xF5), aggiunto da EIP-1014 nell’aggiornamento Constantinople del 28 febbraio 2019 (blocco 7.280.000), deriva dall’indirizzo del creatore, da un salt scelto dal creatore e dall’hash del codice di inizializzazione. Il risultato è un indirizzo che si può calcolare, e perfino finanziare, prima che il contratto esista: lo usano molto i wallet intelligenti e i contratti factory.
Anche l’eliminazione del codice è cambiata. Da Dencun, EIP-6780 fa sì che SELFDESTRUCT cancelli un conto solo se viene chiamato nella stessa transazione che ha creato il contratto; altrimenti invia soltanto il saldo altrove. La lista di Glamsterdam aggiunge EIP-8246, intitolato «Remove SELFDESTRUCT Burn».
L’aggiornamento Pectra del 7 maggio 2025 ha aggiunto una novità all’hash del codice degli EOA. Con EIP-7702, un EOA può firmare un’autorizzazione che scrive nel proprio campo del codice un designatore di delega di 23 byte, 0xef0100 seguito dall’indirizzo di un contratto. Le chiamate all’EOA eseguono allora il codice del contratto delegato nel contesto dell’EOA. Il 10 novembre 2026 un designatore di questo tipo si trovava nel codice di almeno un indirizzo noto della mainnet. Potete controllare allo stesso modo il vostro indirizzo: un risultato di eth_getCode che inizia con 0xef0100 significa che è delegato.
Precompilati: codice nativo agli indirizzi più bassi
Alcune operazioni sarebbero troppo lente o troppo costose in bytecode EVM, quindi il protocollo le offre come contratti precompilati a indirizzi fissi. Si chiamano come qualunque contratto, ma girano come codice nativo dentro ogni client. EIP-2929 li considera «a caldo» fin dall’inizio di ogni transazione.
| Indirizzo | Funzione | Arrivato con |
|---|---|---|
| 0x01 | ecrecover: recupera chi ha firmato una firma secp256k1 | Dal lancio, 2015 |
| Da 0x02 a 0x04 | SHA-256, RIPEMD-160, identità (copia di dati) | Dal lancio, 2015 |
| 0x05 | MODEXP: elevamento a potenza modulare | Byzantium, 16 ottobre 2017 |
| Da 0x06 a 0x08 | Curva alt_bn128: addizione, moltiplicazione, verifica di pairing | Byzantium, 16 ottobre 2017 |
| 0x09 | Funzione di compressione F di BLAKE2 | Istanbul, 8 dicembre 2019 |
| 0x0a | Valutazione di punti KZG (prove dei blob) | Cancun, 13 marzo 2024 |
| Da 0x0b a 0x11 | Sette operazioni sulla curva BLS12-381 | Prague (Pectra), 7 maggio 2025 |
| 0x100 | P256VERIFY: verifica le firme secp256r1 (P-256) | Osaka (Fusaka), 3 dicembre 2025 |
L’elenco deriva dagli insiemi di precompilati nel codice sorgente di Go Ethereum, uno per ogni fork. I precompilati contano anche fuori da Ethereum: le catene che si dicono compatibili con l’EVM non sempre offrono lo stesso insieme, e un contratto che ne dipende può fallire altrove.
Una transazione, dalla firma alla ricevuta
I controlli prima che giri qualunque codice
Una transazione è di uno dei cinque tipi: 0 (legacy), 1 (liste di accesso, EIP-2930), 2 (commissioni EIP-1559, oggi lo standard), 3 (transazioni blob, EIP-4844) e 4 (autorizzazioni EIP-7702). Prima che giri un solo opcode, il client verifica che dalla firma si ricavi un mittente, che il nonce corrisponda a quello del conto del mittente, che il saldo copra il limite di gas moltiplicato per la commissione massima più gli eventuali ETH inviati, e che il limite di gas copra il gas intrinseco: 21.000, più i costi per calldata, liste di accesso e creazione di contratti. Da Fusaka il limite di gas deve anche restare pari o inferiore a 16.777.216. Una transazione che non supera questi controlli non viene inclusa affatto e non costa nulla.
Esecuzione, revert e conferma
Superati questi controlli, il nonce del mittente aumenta, il gas viene pagato in anticipo e l’EVM esegue il codice del destinatario. L’esecuzione termina con STOP o RETURN (successo), con REVERT (0xFD, un fallimento voluto che può restituire un messaggio di errore) oppure con un arresto eccezionale come gas esaurito o opcode non valido. Un fallimento annulla ogni modifica di stato del frame che ha fallito, storage transitorio compreso, ma non il gas speso. Una transazione fallita compare comunque nel suo blocco, fa comunque aumentare il nonce e paga comunque.
Svuotare lo storage dà diritto a un rimborso parziale di gas, limitato dall’aggiornamento London del 5 agosto 2021 a un quinto del gas usato (EIP-3529). La lista di Glamsterdam include EIP-7778, che smette di contare i rimborsi quando si misura quanto è pieno un blocco.
I wallet chiedono a un nodo di stimare il gas necessario a una transazione, con la chiamata eth_estimateGas, e la risposta di solito supera l’uso reale. Per il nostro programma di nove byte la stima del 10 novembre 2026 è stata di 43.488 gas, contro i 43.112 effettivamente necessari. Il margine è voluto: una transazione che resta senza gas fallisce e paga comunque il gas che ha bruciato.
Ricevute e log: che cosa lascia dietro di sé una transazione
Ogni transazione produce una ricevuta: il suo stato (1 per successo, 0 per fallimento), il gas usato e i log emessi. I log sono scritti dagli opcode da LOG0 a LOG4. I contratti non possono leggerli; esistono per wallet, explorer e app, e costano molto meno dello storage. L’intestazione del blocco si impegna su tutte le ricevute tramite una radice delle ricevute, proprio come fa con lo stato.
Un esempio dal vivo: la transazione 0x7c26…416b, nel blocco 26.383.708 del 10 novembre 2026, ha chiamato il contratto USDT con il selettore 0xa9059cbb. Aveva un limite di gas di 64.043, ne ha usati 63.209 ed è andata a buon fine. La sua ricevuta contiene un log del contratto USDT. Il primo topic, 0xddf2…b3ef, è l’hash Keccak-256 di Transfer(address,address,uint256); il secondo e il terzo topic sono mittente e destinatario; il campo dati è l’importo, 58.709.442 in unità grezze, cioè 58,709442 USDT dato che il contratto dichiara sei decimali. La nostra guida a come leggere un block explorer mostra dove compaiono questi campi su Etherscan.
Chi fa girare la macchina: cinque execution client e un legame con il consenso
Geth, Nethermind, Besu, Erigon e Reth, contati in modi diversi
Come specifica, l’EVM non fa nulla da sola. Gira dentro gli execution client, i programmi che ricevono le transazioni, le eseguono e conservano lo stato. Ethereum.org elenca Geth (Go), Nethermind (C# .NET), Besu (Java), Erigon (Go) e Reth (Rust), più il più recente ethrex (Rust). La nostra guida a che cos’è un nodo spiega come si incastrano su una macchina.
Dire quanti nodi eseguano ciascun client è più difficile di quanto sembri. Le fonti misurano cose diverse e non concordano.
| Fonte (pagine lette il 10 nov 2026) | Che cosa misura | Geth | Nethermind | Besu | Reth | Erigon |
|---|---|---|---|---|---|---|
| Ethernodes, mostrato su clientdiversity.org, aggiornato ogni giorno | Nodi visibili a un crawler con slot di peer liberi | 50,13% | 25,46% | 9,45% | 7,67% | 6,53% |
| supermajority.info, mostrato su clientdiversity.org, aggiornato a mano | Dichiarazioni degli operatori, 59,4% della rete coperta, in gran parte vecchie di oltre un anno | 43% | 43% | 8% | 3% | 3% |
| Istantanea di supermajority.info del 26 ott 2025, mostrata su ethereum.org | Dichiarazioni degli operatori | 41% | 38% | 16% | 2% | 3% |
Clientdiversity.org avverte che i numeri di Ethernodes riflettono quali client mostrano peer liberi, che non è «ben compreso» come ciò si rapporti a quanto gli operatori eseguono davvero (testo originale in inglese), e indica come fonte più affidabile i dati di sondaggio di execution-diversity.info. La pagina sulla diversità dei client di ethereum.org mostra nell’ultima riga l’istantanea di ottobre 2025, mentre un’altra frase della stessa pagina attribuisce ancora a Geth «around 85%» dei nodi, una cifra degli anni passati. La sintesi corretta: Geth ha perso la sua vecchia supermaggioranza e, a seconda del metodo, esegue tra quattro e cinque nodi su dieci.
L’Engine API: come l’EVM riceve gli ordini dalla Merge
Dalla Merge del 15 settembre 2022 (blocco 15.537.394), un execution client non decide più quale blocco venga dopo. Un client di consenso separato, come Lighthouse, Prysm, Teku, Nimbus, Lodestar o Grandine, gestisce la proof of stake e dice all’execution client che cosa fare tramite l’Engine API: engine_newPayload gli consegna un blocco da eseguire e controllare, ed engine_forkchoiceUpdated gli dice quale testa della catena seguire o gli chiede di costruire un blocco. La specifica dell’Engine API dice che il livello di consenso «guida» il livello di esecuzione, su una porta dedicata (8551 per impostazione predefinita) protetta da autenticazione JWT. Come funziona il lato del consenso è il tema della nostra lezione successiva sulla Merge e la proof of stake.
Perché il bug di un client conta: le soglie di un terzo e di due terzi
Sul livello di consenso le soglie sono aritmetica. Secondo ethereum.org, un bug in un client di consenso usato da più di un terzo dei nodi potrebbe impedire alla catena di finalizzare, e un bug critico in un client con due terzi della rete potrebbe finalizzare una catena non valida, lasciando i suoi validatori bloccati ed esposti allo slashing. Clientdiversity.org fissa lo stesso obiettivo per ogni client, una quota sotto il 33%, e dice che i rischi «apply to both consensus clients and execution clients equally» (testo originale in inglese).
L’episodio di Reth del novembre 2026 mostra l’altra faccia della medaglia. Reth gira sul 2% fino all’8% dei nodi Ethereum, a seconda del conteggio nella tabella, lontano dalla soglia di un terzo. Base, BSC-Reth di BNB Chain e Tempo, invece, usano nodi basati su Reth, e per loro lo stesso bug è stato un motivo per correggere nel giro di pochi giorni. Il rischio di un bug in un client dipende da quanti nodi di una data rete usano quel client.
La stessa macchina su altre catene
Compatibile con l’EVM, equivalente all’EVM e chain ID
Poiché l’EVM è una specifica pubblicata con diverse implementazioni open source, decine di altre reti la eseguono. L’elenco delle catene di DefiLlama, letto il 10 novembre 2026, ne traccia 422, di cui 238 con un chain ID registrato, il numero che i wallet EVM usano per distinguere le reti. Le più grandi per valore totale bloccato, secondo DefiLlama alla stessa data, sono qui sotto.
| Catena | Valore bloccato secondo DefiLlama (10 nov 2026) | Chain ID | Nota |
|---|---|---|---|
| Ethereum | 41,74 miliardi di dollari | 1 | L’EVM di riferimento |
| Base | 5,72 miliardi di dollari | 8453 | Layer 2 costruito su OP Stack |
| BNB Smart Chain | 5,10 miliardi di dollari | 56 | Un proprio insieme di validatori |
| Arbitrum | 1,40 miliardi di dollari | 42161 | Optimistic rollup |
| Monad | 0,94 miliardi di dollari | 143 | Layer 1 separato |
| Polygon | 0,62 miliardi di dollari | 137 | Catena Polygon PoS |
| Avalanche | 0,61 miliardi di dollari | 43114 | C-Chain |
Il chain ID è firmato dentro ogni transazione moderna (EIP-155, anch’esso di Spurious Dragon), quindi una transazione valida su una rete non può essere riprodotta su un’altra. Gli indirizzi, invece, usano lo stesso formato di 20 byte su ogni catena EVM. La stessa chiave privata controlla lo stesso indirizzo su Ethereum, Base o BNB Chain: è comodo, ed è anche il motivo per cui i fondi inviati sulla rete sbagliata possono arrivare a un indirizzo che il proprietario non intendeva usare lì.
«Compatibile con l’EVM» significa che una catena esegue lo stesso bytecode con la stessa semantica di base. Non promette prezzi del gas, precompilati, tempi di blocco o ultimi opcode identici. I rollup che si regolano su Ethereum, messi a confronto nella nostra guida a layer 1 e layer 2, tendono a seguire da vicino la mainnet; la nostra lezione successiva sul layer 2 andrà più a fondo.
I tipi di zkEVM da 1 a 4 di Vitalik Buterin
I rollup a conoscenza zero affrontano una versione più difficile della questione, perché devono dimostrare l’esecuzione dell’EVM, e alcune sue caratteristiche sono costose da dimostrare. In un post del 4 agosto 2022, Vitalik Buterin ha classificato gli zkEVM in tipi. «Type 1 ZK-EVMs strive to be fully and uncompromisingly Ethereum-equivalent», ha scritto (testo originale in inglese); ogni tipo successivo cede un po’ di equivalenza in cambio di prove più rapide.
| Tipo | Che cosa mantiene e che cosa cambia |
|---|---|
| 1 | Esattamente Ethereum, compresi hash e alberi di stato: il più lento da dimostrare |
| 2 | Equivalente all’EVM, ma cambia strutture esterne come l’albero di stato per accelerare le prove |
| 2.5 | Come il tipo 2, con prezzi del gas più alti per le operazioni difficili da dimostrare |
| 3 | Quasi equivalente: elimina o altera alcune caratteristiche, per esempio certi precompilati |
| 4 | Compila il sorgente Solidity o Vyper in un linguaggio adatto alle prove, aggirando il bytecode EVM |
La classificazione risale al 2022 e da allora i progetti si sono spostati da un tipo all’altro. A quale tipo appartenga oggi una rete lo deve dire la documentazione di ciascun progetto.
Come cambia l’EVM nel tempo
Fork dopo fork: gli aggiornamenti che hanno cambiato la macchina
La macchina di Ethereum non è mai stata congelata. La tabella elenca gli aggiornamenti che l’hanno cambiata di più, con date e blocchi dalla pagina di storia di ethereum.org e il contenuto dagli EIP.
| Aggiornamento | Data (UTC) e blocco | Che cosa è cambiato nell’EVM |
|---|---|---|
| Spurious Dragon | 22 nov 2016, blocco 2.675.000 | Limite di codice di 24.576 byte (EIP-170), chain ID nelle firme (EIP-155) |
| Byzantium | 16 ott 2017, blocco 4.370.000 | Precompilati MODEXP e alt_bn128 |
| Constantinople | 28 feb 2019, blocco 7.280.000 | CREATE2 (EIP-1014) |
| Istanbul | 8 dic 2019, blocco 9.069.000 | Precompilato BLAKE2 |
| Berlin | 15 apr 2021, blocco 12.244.000 | Prezzi di accesso a freddo e a caldo (EIP-2929), liste di accesso (EIP-2930) |
| London | 5 ago 2021, blocco 12.965.000 | Commissioni EIP-1559, rimborsi limitati (EIP-3529) |
| Shanghai (Shapella) | 12 apr 2023, blocco 17.034.870 | PUSH0 (EIP-3855), limite del codice di inizializzazione (EIP-3860) |
| Cancun (Dencun) | 13 mar 2024, blocco 19.426.587 | Storage transitorio, MCOPY, SELFDESTRUCT limitato, blob e precompilato KZG |
| Prague (Pectra) | 7 mag 2025, blocco 22.431.084 | Delega del codice degli EOA (EIP-7702), precompilati BLS12-381 |
| Osaka (Fusaka) | 3 dic 2025, blocco 23.935.694 | Opcode CLZ, P256VERIFY, tetto di gas per transazione, limite di gas predefinito di blocco a 60M |
Glamsterdam: una revisione dei prezzi che potrebbe rompere i contratti con gas fissato nel codice
Il prossimo aggiornamento, Glamsterdam, ha una lista programmata nel suo meta EIP-7773. Oltre alle novità principali, la separazione proposer-builder integrata nel protocollo (trattata nella nostra guida a protezione dall’MEV e PBS) e le liste di accesso a livello di blocco, tocca direttamente l’EVM: un opcode SLOTNUM (EIP-7843), le istruzioni di pila più profonde di EIP-8024, contratti più grandi (EIP-7954), un log per ogni trasferimento di ETH (EIP-7708) e un nuovo schema del gas.
Il nuovo schema è la parte sensibile. EIP-8037 prezza la creazione di stato a byte: 1.530 gas per ogni nuovo byte di stato. Un nuovo conto vale 120 byte, quindi 183.600 gas contro 25.000 con le regole attuali; un nuovo slot di storage vale 64 byte, 97.920 gas contro 20.000. EIP-8038 alza il costo di lettura e scrittura dello stato esistente. Entrambi gli EIP erano in stato Last Call il 10 novembre 2026. Il post del 24 agosto 2026 della Ethereum Foundation dice che il nuovo schema deriva da un obiettivo di circa tre volte più throughput di base e che, rieseguendo con esso le transazioni storiche della mainnet, emerge che «a small set of smart contracts» si affida a ipotesi che lo schema sposta. «Most flagged issues are fixed with a gas-limit increase», aggiunge il post (testo originale in inglese). I contratti che possono rompersi anche con più gas sono quelli che si affidano a sussidi fissi come i 2.300 gas di transfer e send di Solidity, scrivono nel codice valori di gas nelle chiamate, decidono in base al gas rimanente o dipendono da transazioni prefirmate con limiti di gas fissi.
Non tutti sono rassicurati. L’8 novembre 2026 due sviluppatori hanno depositato bozze concorrenti per proteggere i vecchi contratti, come illustra il nostro articolo su le proposte rivali per Glamsterdam: la pull request 12638 di Leo Glisic darebbe una versione agli opcode, in modo che i contratti esistenti mantengano i vecchi prezzi, e la pull request 12637 di Giulio Rebuffo separerebbe il gas che un contratto vede da quello che gli viene addebitato. Entrambe erano ancora aperte su GitHub il 10 novembre 2026, senza codice dei client. Gli sviluppatori core si incontrano il 12 novembre (ACDC #191) e il 19 novembre (ACDE #249), e Glamsterdam non ha una data sulla mainnet.
EOF: né in Fusaka né in Glamsterdam
L’EVM Object Format (EOF) era un piano preparato a lungo per avvolgere il bytecode in un contenitore strutturato che separa codice e dati e viene validato al deploy. Non è nella lista finale di Fusaka (EIP-7607) né in quella programmata di Glamsterdam (EIP-7773), e il suo meta EIP, EIP-7692, è contrassegnato come Stagnant al 10 novembre 2026.
RISC-V: una proposta del 2025, non un piano
Il 20 aprile 2025 Vitalik Buterin ha pubblicato sul forum Ethereum Magicians una proposta a lungo termine per «replace the EVM with RISC-V as the virtual machine language that smart contracts are written in» (testo originale in inglese). Conti, storage e chiamate tra contratti resterebbero come sono; opcode come SLOAD, SSTORE e CALL diventerebbero chiamate di sistema; i vecchi contratti EVM continuerebbero a funzionare e a interagire con quelli nuovi. Il suo motivo è la dimostrazione: ha scritto che l’esecuzione dei blocchi rappresentava allora circa metà del lavoro dei prover a conoscenza zero, quindi una macchina virtuale più vicina a quella che i prover già usano aiuterebbe. Le risposte nel thread osservano che l’EVM lavora nativamente con numeri a 256 bit, che una macchina RISC-V dovrebbe spezzare in pezzi più piccoli, a scapito della velocità. Al 10 novembre 2026 l’idea non è nella lista di alcun aggiornamento.
Che cosa significa la macchina per utenti, sviluppatori e tribunali
Per uno sviluppatore, il modello di costo dell’EVM è il progetto stesso: ogni slot di storage evitato fa risparmiare migliaia di gas, e ogni cifra di gas scritta nel codice è una scommessa su uno schema che Glamsterdam sta per cambiare. Per un utente, da questa lezione discendono due abitudini. Una transazione fallita costa comunque gas, quindi l’avviso di un wallet secondo cui una transazione fallirà merita attenzione. E un rapido eth_getCode sul vostro indirizzo, o la scheda del codice di un explorer, vi dice se porta una delega EIP-7702 che non volevate.
Il codice senza proprietario è arrivato anche nei tribunali. Il 26 novembre 2024, nel caso Van Loon v. Department of the Treasury, la Corte d’appello degli Stati Uniti per il Quinto Circuito ha stabilito che «Tornado Cash’s immutable smart contracts (the lines of privacy-enabling software code) are not the ‘property’ of a foreign national or entity», quindi l’OFAC non poteva bloccarli in base alla legge sulle sanzioni IEEPA, come afferma il parere della corte (testo originale in inglese). Il parere spiega che gli sviluppatori hanno rinunciato al controllo sui contratti dei pool in una «trusted setup ceremony» del 2020, dopo la quale quei contratti sono diventati irreversibilmente immutabili. Il 21 marzo 2025 il Tesoro ha tolto Tornado Cash dalla propria lista di sanzioni, citando «the novel legal and policy issues» sollevati dal sanzionarlo. La decisione riguarda i contratti immutabili; un proxy la cui logica può essere sostituita, come quello dietro USDC, non era davanti alla corte.
Le prossime date da seguire sono le riunioni degli sviluppatori core del 12 novembre (consenso) e del 19 novembre 2026 (esecuzione), entrambe con Glamsterdam all’ordine del giorno. Qualunque cosa decidano sullo schema del gas diventerà parte della funzione che trasforma una state root nella successiva.
