Quando invii ETH, trasferisci un token o interagisci con uno smart contract, la transazione non passa direttamente dal wallet alla blockchain. Prima viene costruita e firmata, poi diffusa tra i nodi della rete, inserita in una coda temporanea e infine inclusa in un blocco da un validatore. Solo dopo ulteriori passaggi può essere considerata sempre più difficile da annullare.
Capire questo percorso aiuta a interpretare correttamente messaggi come “in attesa”, “inclusa”, “fallita” o “sostituita”. Permette anche di distinguere una transazione non ancora registrata da una transazione già presente sulla blockchain ma conclusa con un errore. Questa guida descrive il ciclo di vita di una transazione Ethereum senza confonderlo con la lettura dei singoli eventi o delle commissioni, che sono aspetti collegati ma distinti.
1. La costruzione della transazione: cosa contiene davvero
Una transazione Ethereum è un messaggio firmato digitalmente che autorizza un’operazione da un account controllato da una chiave privata. Il wallet prepara i dati necessari, ma non trasferisce la chiave privata alla rete: la firma viene prodotta localmente dal wallet o dal dispositivo di custodia.
In una transazione possono comparire diversi elementi:
- Indirizzo del mittente: viene ricavato dalla firma e identifica l’account che autorizza l’operazione.
- Indirizzo del destinatario: può appartenere a un altro account oppure a uno smart contract.
- Valore: indica quanti ETH vengono trasferiti direttamente, se previsto.
- Dati: contengono le istruzioni per interagire con un contratto, per esempio effettuare uno swap o depositare fondi.
- Nonce: è un contatore progressivo associato all’account mittente.
- Limite e prezzo del gas: definiscono quanta computazione può utilizzare l’operazione e quanto il mittente è disposto a pagare.
- Identificativi della rete: impediscono, tra le altre cose, di riutilizzare la stessa transazione su una rete diversa.
Il nonce merita particolare attenzione. Per un determinato account, le transazioni valide devono normalmente essere eseguite in ordine: se la prossima transazione attesa ha nonce 12, una transazione con nonce 13 può restare in sospeso finché quella con nonce 12 non viene inclusa o sostituita. Il nonce non è quindi un numero casuale né un identificativo universale della transazione: è il numero progressivo delle operazioni inviate da quello specifico account.
Una volta firmata, la transazione viene trasmessa a un nodo Ethereum tramite il wallet, un provider RPC o un’infrastruttura analoga. In questa fase non è ancora nella blockchain.
2. Dalla trasmissione alla mempool
La mempool, abbreviazione di memory pool, è l’insieme delle transazioni valide che un nodo conosce ma che non sono ancora state incluse in un blocco. Non esiste una singola mempool globale identica per tutta la rete: ogni nodo mantiene una propria vista, che può differire temporaneamente da quella degli altri nodi.
Quando riceve una transazione, il nodo esegue diversi controlli preliminari. Verifica, tra gli altri aspetti, che la firma sia corretta, che la transazione appartenga alla rete prevista, che il nonce sia coerente e che l’account disponga di fondi sufficienti per coprire il valore trasferito e il costo massimo autorizzato. Se i controlli falliscono, il nodo può rifiutare la transazione senza diffonderla ulteriormente.
Se la transazione supera questi controlli, viene inoltrata ad altri nodi e può entrare nella loro mempool. Il wallet può quindi mostrare uno stato di attesa anche quando la transazione non è ancora stata vista da tutti i partecipanti alla rete. La velocità di propagazione dipende dalla connettività, dal provider utilizzato, dalle regole dei nodi e dalle condizioni della rete.
La mempool non è una prenotazione di spazio nel prossimo blocco. Una transazione presente nella coda può rimanere in attesa, essere rimossa, essere sostituita da una nuova transazione con lo stesso nonce oppure non essere mai inclusa. Un esploratore blockchain può inoltre mostrare informazioni diverse dal wallet, perché interroga nodi e infrastrutture differenti.
3. Il ruolo del validatore e l’inclusione nel blocco
Ethereum utilizza un sistema proof of stake. A turno, un validatore viene incaricato di proporre un blocco, mentre altri validatori partecipano al processo di attestazione. Il proponente seleziona un insieme di transazioni disponibili, normalmente cercando di rispettare le regole del protocollo e gli incentivi economici legati alle commissioni.
Il validatore non può modificare liberamente una transazione firmata. Può però decidere quali transazioni includere e in quale ordine, entro i vincoli del protocollo. Per esempio, una transazione con un certo nonce deve rispettare la sequenza prevista per l’account mittente. Se una transazione utilizza più gas di quanto consentito dal limite, l’esecuzione può terminare con un errore, pur restando registrata nel blocco.
Quando il blocco viene proposto e diffuso, gli altri partecipanti verificano la correttezza delle transazioni e dell’esecuzione complessiva. Se il blocco viene accettato dalla rete, la transazione passa da “in attesa” a inclusa. A questo punto esiste una registrazione on-chain consultabile tramite il relativo transaction hash.
L’inclusione non significa necessariamente che l’operazione abbia prodotto il risultato desiderato. Una transazione può essere inclusa ma fallire perché, per esempio, una condizione dello smart contract non è stata rispettata, il limite del gas era insufficiente oppure il contratto ha eseguito un’istruzione di revert. In questo caso la commissione può comunque essere dovuta, perché la rete ha consumato risorse per elaborare la richiesta.
4. Conferme, attestazioni e finalità
Dopo l’inclusione, la transazione si trova in un blocco che diventa parte della catena riconosciuta dalla rete. I blocchi successivi aumentano la distanza temporale e strutturale rispetto alla transazione. Questa distanza viene spesso indicata come numero di conferme, anche se il significato operativo della conferma può variare tra wallet, exchange e applicazioni.
È utile distinguere tre concetti:
- Inclusione: la transazione è stata inserita in un blocco.
- Conferme successive: altri blocchi sono stati aggiunti dopo quello che contiene la transazione.
- Finalità: la rete ha raggiunto un livello di accordo che rende estremamente improbabile, secondo il funzionamento del protocollo, la sostituzione della storia considerata definitiva.
Prima della finalità, una transazione inclusa può, in circostanze anomale, essere coinvolta in una riorganizzazione della catena, chiamata reorg. Una reorg può verificarsi quando parti della rete riconoscono temporaneamente blocchi diversi o quando un blocco viene escluso dalla storia canonica. Non significa automaticamente che i fondi siano persi: la transazione può essere reinserita in un blocco successivo, oppure può dover essere nuovamente valutata se dipende da operazioni concorrenti.
Per i trasferimenti di valore relativamente importanti, servizi come gli exchange possono attendere un certo numero di blocchi o un livello di finalità prima di accreditare i fondi. Questa scelta è una regola operativa del servizio e non modifica il funzionamento di base della rete.
5. Perché una transazione resta bloccata o viene sostituita
Uno dei casi più comuni è una sequenza di nonce bloccata. Se una transazione con nonce più basso rimane in attesa, anche quelle successive dello stesso account possono non essere eseguite. In pratica, il problema della prima transazione si propaga a quelle che dipendono dall’ordine.
Un altro caso riguarda una commissione non sufficientemente competitiva rispetto alle condizioni del momento. La transazione può essere valida ma non essere scelta rapidamente dai proponenti dei blocchi. Aumentare semplicemente la commissione di una nuova transazione con nonce successivo non risolve sempre il problema, perché l’ordine dei nonce resta vincolante.
Molti wallet permettono di accelerare o annullare una transazione inviandone un’altra con lo stesso nonce e parametri di commissione più adatti. Si tratta di una sostituzione, non della cancellazione retroattiva della prima transazione. Se la transazione originale è già stata inclusa, una successiva con lo stesso nonce non può normalmente essere eseguita come se la prima non esistesse.
Una “cancel transaction” è di solito una transazione verso il proprio indirizzo, con lo stesso nonce della transazione pendente. Se viene inclusa per prima, impedisce l’esecuzione dell’operazione originaria con quel nonce. Tuttavia non è una garanzia assoluta finché una delle due transazioni non è stata inclusa, e la procedura può comportare ulteriori costi.
6. Errori pratici da evitare
- Confondere hash e nonce: l’hash identifica una specifica transazione, mentre il nonce identifica la posizione dell’operazione nella sequenza del mittente.
- Considerare “pending” come “fallita”: pending indica in genere che la transazione non è ancora stata inclusa; non descrive il risultato finale dell’esecuzione.
- Inviare molte transazioni in rapida successione senza controllare i nonce: può creare una coda difficile da gestire, soprattutto se una delle prime operazioni resta bloccata.
- Ritentare alla cieca dopo un rallentamento: una nuova transazione potrebbe duplicare l’operazione, se la precedente venisse poi inclusa.
- Affidarsi a una sola schermata del wallet: per verificare lo stato è preferibile confrontare hash, rete, blocco, stato dell’esecuzione e destinatario su un esploratore affidabile.
- Confondere una transazione fallita con un trasferimento riuscito: bisogna controllare lo stato on-chain e, quando si interagisce con un contratto, anche gli eventi e i movimenti effettivamente prodotti.
7. Un esempio semplice del ciclo completo
Immaginiamo che un account debba inviare ETH a un altro indirizzo. Il wallet legge il nonce corrente, prepara destinatario, valore, dati e parametri del gas, quindi mostra i dettagli all’utente. Dopo la conferma, la chiave privata firma la transazione e il wallet la trasmette a un nodo.
Il nodo verifica firma, rete, nonce e disponibilità economica. Se tutto è valido, diffonde la transazione e la conserva nella propria mempool. Un validatore la seleziona per un blocco. Quando il blocco viene accettato, l’esploratore può mostrare il transaction hash, il numero del blocco e lo stato dell’esecuzione.
Se il trasferimento era un semplice invio di ETH e l’esecuzione è andata a buon fine, il saldo del destinatario cambia. Se invece la transazione chiamava uno smart contract, il risultato deve essere verificato considerando anche gli eventi emessi, eventuali trasferimenti di token e lo stato finale del contratto. I blocchi successivi e la finalità aumentano poi il grado di sicurezza della registrazione.
Il percorso completo chiarisce perché il pulsante “Conferma” non equivale alla conclusione dell’operazione. In Ethereum esistono fasi diverse, ciascuna con condizioni e rischi propri: firma, propagazione, mempool, inclusione, esecuzione e finalità. Leggere correttamente queste fasi è il modo più affidabile per capire cosa sia realmente accaduto, prima di ripetere un’operazione o intervenire su una transazione pendente.
