Per capire davvero come funziona Ethereum non basta sapere che esistono ether, wallet e smart contract. Ethereum è una rete che mantiene uno stato condiviso e applica regole precise ogni volta che una transazione chiede di modificarlo. Il risultato deve essere verificabile e identico per tutti i nodi, anche se nessun soggetto centrale esegue l’operazione per conto della rete.
In termini semplici, Ethereum può essere visto come un grande computer distribuito: non è un computer unico, non conserva i dati in un solo server e non esegue istruzioni arbitrariamente. I nodi applicano la Ethereum Virtual Machine, o EVM, seguendo le stesse regole. In questo modo un trasferimento di ether, un deposito in un protocollo DeFi o uno scambio su un’applicazione decentralizzata diventano trasformazioni verificabili dello stato della blockchain.
Questa guida si concentra su ciò che avviene sotto la superficie: la differenza tra account, il ruolo del nonce, l’esecuzione degli smart contract e il modo in cui una transazione cambia lo stato di Ethereum.
Che cosa significa “stato” su Ethereum
Lo stato di Ethereum è l’insieme delle informazioni che descrivono la situazione corrente della rete. Tra queste rientrano i saldi degli account, i contatori delle transazioni, il codice degli smart contract e i dati memorizzati dai contratti.
Ogni nuovo blocco contiene operazioni che, se valide, trasformano lo stato precedente in uno stato successivo. In forma semplificata:
stato precedente + transazioni valide = nuovo stato
Non è quindi corretto immaginare la blockchain soltanto come una lista di movimenti. Un trasferimento modifica il saldo di almeno due account, mentre l’interazione con un contratto può modificare molte variabili: un saldo interno, una posizione di liquidità, un prezzo registrato da un oracolo o il proprietario di un NFT.
La rete non conserva necessariamente ogni valore in modo intuitivo o leggibile dall’utente. I dati sono organizzati in strutture tecniche ottimizzate per essere verificati dai nodi. Il blocco contiene inoltre un riferimento crittografico allo stato risultante. Se una modifica non autorizzata alterasse anche una sola informazione, il riferimento non corrisponderebbe più.
I due tipi di account Ethereum
Ethereum distingue due categorie principali di account. La distinzione è essenziale perché solo una delle due può avviare autonomamente una transazione.
Gli account controllati esternamente, spesso chiamati EOA, sono associati a una chiave privata. Un wallet non “contiene” le monete in senso fisico: gestisce chiavi che permettono di autorizzare operazioni riguardanti determinati indirizzi. Un EOA ha normalmente un saldo in ether e un nonce, cioè un contatore delle transazioni inviate da quell’account.
Gli account contratto possiedono invece codice eseguibile e memoria persistente. Non hanno una chiave privata equivalente a quella di un EOA. Il loro comportamento dipende dal codice pubblicato sulla rete e dalle regole previste da quel codice. Un contratto può detenere ether o token, registrare dati e chiamare altri contratti quando viene eseguito.
Un wallet, dunque, non è la stessa cosa di un account e un token non è normalmente un oggetto custodito dentro il wallet. Nel caso di un token compatibile con gli standard più comuni, il saldo è registrato nel contratto del token, che associa indirizzi e quantità. Il wallet legge quel dato e presenta all’utente un saldo comprensibile.
Che cos’è una transazione Ethereum
Una transazione è un messaggio firmato digitalmente che chiede alla rete di eseguire un’azione. Può essere un trasferimento semplice verso un altro indirizzo oppure una chiamata a uno smart contract.
Tra le informazioni più importanti di una transazione rientrano:
- l’indirizzo del mittente, ricavato dalla firma e dalla chiave pubblica;
- l’indirizzo destinatario, che può appartenere a un EOA o a un contratto;
- il valore di ether eventualmente trasferito;
- il limite di gas e i parametri economici dell’operazione;
- il nonce del mittente;
- i dati della chiamata, spesso chiamati calldata, quando si interagisce con un contratto;
- la firma digitale che dimostra l’autorizzazione del mittente.
Il campo dati è particolarmente importante. Quando un’interfaccia mostra un’azione come “depositare”, “scambiare” o “coniare”, in genere sta preparando una chiamata a una funzione di uno smart contract. Il wallet firma una transazione contenente i parametri codificati della funzione. La rete non interpreta il pulsante dell’interfaccia: esegue byte e dati secondo le regole dell’EVM.
Il ruolo del nonce
Il nonce è un contatore associato a ogni account controllato esternamente. Serve principalmente a impedire il riutilizzo della stessa transazione e a mantenere l’ordine delle operazioni provenienti da un determinato indirizzo.
Se un account ha già inviato un certo numero di transazioni valide, la successiva dovrà utilizzare il nonce previsto. Una transazione con nonce già utilizzato può essere rifiutata o considerata sostituzione secondo le regole applicabili; una transazione con nonce troppo alto può rimanere in attesa finché non vengono elaborate quelle precedenti.
Questo spiega alcuni comportamenti apparentemente strani: una transazione bloccata può impedire la gestione ordinata delle successive, mentre due operazioni preparate quasi contemporaneamente possono entrare in conflitto se usano lo stesso nonce. Il problema non riguarda necessariamente il saldo o la seed phrase, ma l’ordine delle richieste inviate da quell’account.
Il nonce non va confuso con il numero di conferme di una transazione e nemmeno con un identificativo universale. È un contatore locale all’account e contribuisce a determinare l’ordine delle sue transazioni.
Come interviene la EVM
La Ethereum Virtual Machine è l’ambiente deterministico nel quale viene eseguito il bytecode degli smart contract. Deterministico significa che, partendo dallo stesso stato e dalla stessa transazione, i nodi corretti devono arrivare allo stesso risultato.
Il codice che gli sviluppatori scrivono in linguaggi come Solidity viene compilato in bytecode. È questo bytecode, non il codice sorgente leggibile, a essere eseguito dalla rete. Ogni istruzione ha un costo in gas, perché richiede risorse computazionali o modifica dati che i nodi dovranno conservare e verificare.
Durante l’esecuzione, la EVM utilizza diverse aree concettuali:
- lo stack, usato per le operazioni immediate;
- la memoria temporanea, disponibile durante l’esecuzione della chiamata;
- lo storage del contratto, persistente e registrato nello stato della blockchain;
- il calldata, cioè i dati forniti dall’esterno alla funzione chiamata;
- il codice del contratto.
La differenza tra memoria e storage è fondamentale. La memoria serve durante una singola esecuzione e non mantiene i dati dopo la conclusione della chiamata. Lo storage, invece, conserva variabili dello smart contract tra una transazione e l’altra. Scrivere nello storage tende a essere un’operazione costosa perché modifica lo stato condiviso della rete.
Da una chiamata a un contratto al risultato finale
Immaginiamo un utente che utilizzi un’applicazione per depositare token in un contratto. L’interfaccia costruisce una transazione con l’indirizzo del contratto e i dati necessari a identificare la funzione e i suoi parametri. Il wallet mostra la richiesta e, dopo la firma, la diffonde alla rete.
I nodi verificano innanzitutto aspetti di base: firma, nonce, saldo sufficiente per coprire il valore e i costi, formato della transazione e destinazione. Se la transazione è accettabile, viene presa in considerazione per l’inclusione in un blocco.
Quando viene eseguita, la EVM segue il bytecode del contratto. Potrebbe controllare che l’utente abbia autorizzato il trasferimento dei token, aggiornare il saldo interno dell’utente e modificare il saldo del contratto. Potrebbe inoltre emettere eventi, chiamare un altro contratto o verificare condizioni aggiuntive.
Il risultato può essere:
- un’esecuzione completata, con aggiornamento dello stato;
- un’esecuzione revertita, nella quale gli aggiornamenti di stato della chiamata vengono annullati;
- un’esecuzione interrotta perché il gas disponibile non è sufficiente o perché si verifica un errore.
Una transazione revertita non equivale sempre a una transazione inesistente. L’esecuzione può aver consumato risorse prima dell’errore e il costo associato può restare dovuto, mentre le modifiche di stato della chiamata fallita vengono generalmente annullate. Per questo è importante distinguere tra “transazione inclusa”, “esecuzione riuscita” e “stato finale”.
Chiamate interne ed eventi
Una singola transazione può attivare una catena di chiamate tra più contratti. L’utente vede una transazione principale, ma durante l’esecuzione il contratto destinatario può chiamare un contratto di token, un router o altri componenti.
Queste operazioni sono spesso chiamate internal transactions in modo informale. Non sono però transazioni autonome firmate da un nuovo utente: sono messaggi generati durante l’esecuzione di una transazione già autorizzata. La distinzione è utile quando si ricostruisce ciò che è avvenuto in un protocollo.
Gli eventi, invece, sono registrazioni prodotte dal contratto per rendere più semplice l’analisi da parte di interfacce e strumenti esterni. Un evento può segnalare un trasferimento, un deposito o una variazione di proprietà. Non sostituisce lo stato del contratto e non è, da solo, una prova sufficiente per interpretare ogni conseguenza economica: deve essere letto insieme al codice e al contesto della transazione.
Perché una transazione può essere tecnicamente valida ma economicamente rischiosa
La validità secondo il protocollo non significa che l’operazione sia sicura o conveniente per l’utente. Se una transazione rispetta le regole della rete e il contratto la accetta, Ethereum può eseguirla anche quando l’utente ha interpretato male la richiesta.
Tra i rischi principali ci sono:
- inviare fondi a una funzione o a un indirizzo errato;
- approvare a un contratto la possibilità di movimentare più token del necessario;
- interagire con codice vulnerabile o malevolo;
- confondere una chiamata di sola lettura con una transazione che modifica lo stato;
- non comprendere i parametri codificati nella richiesta;
- considerare definitivo un risultato prima che la finalità e la situazione della rete siano sufficientemente consolidate.
Un contratto può essere immutabile, aggiornabile tramite proxy o controllato da meccanismi amministrativi. La presenza di codice verificato pubblicamente è utile per l’analisi, ma non elimina automaticamente bug, rischi economici o comportamenti indesiderati.
Un metodo pratico per interpretare ciò che sta accadendo
Quando si analizza un’operazione Ethereum, conviene procedere in ordine:
- identificare il mittente e il destinatario della transazione;
- verificare se il destinatario è un account personale o un contratto;
- controllare il valore di ether e la rete utilizzata;
- leggere il risultato dell’esecuzione, distinguendo successo e revert;
- esaminare gli eventi e le eventuali chiamate interne;
- confrontare i saldi o le variabili del contratto prima e dopo l’operazione;
- verificare quali autorizzazioni restano attive dopo l’interazione.
Questo metodo evita di fermarsi al solo movimento visibile nel wallet. Un’interazione che sembra un semplice deposito può includere un’approvazione precedente, un trasferimento di token e una registrazione interna nel protocollo. Allo stesso modo, l’assenza di un nuovo trasferimento di ether non significa che la transazione non abbia modificato altri valori.
Capire Ethereum significa quindi osservare la rete come un sistema di transizioni: gli account forniscono identità e dati, le transazioni chiedono cambiamenti, la EVM esegue il codice e il nuovo stato diventa la base per le operazioni successive. Questa prospettiva aiuta a leggere con maggiore precisione wallet, applicazioni decentralizzate ed esploratori blockchain, senza confondere ciò che l’interfaccia mostra con ciò che il protocollo ha realmente eseguito.
