Transazioni Ethereum in sospeso: nonce, sostituzione e annullamento

Dopo aver firmato una transazione Ethereum, il wallet può inviarla a un client di esecuzione o a un servizio di transazione. I nodi che la accettano possono inoltrarla ai peer e un proponente di blocco potrà poi includerla in un blocco. Prima dell’inclusione, la transazione non ha modificato lo stato canonico della blockchain. L’etichetta “pending” in un wallet o in un explorer di solito significa che il servizio conosce la transazione ma non l’ha ancora osservata in un blocco; non identifica una coda di rete universale. La guida alle transazioni di Ethereum.org descrive il percorso dalla firma e dalla trasmissione fino all’inclusione in un blocco.

Una transazione può restare in attesa per vari motivi. I limiti delle commissioni potrebbero non soddisfare le condizioni per un blocco, una transazione precedente dello stesso account potrebbe essere ancora irrisolta, un nodo potrebbe non averla ricevuta oppure il wallet potrebbe mostrare informazioni obsolete o specifiche del provider. Ogni causa richiede controlli diversi. Aumentare la commissione non corregge la selezione di una rete sbagliata e inviare un altro pagamento senza controllare il primo può generare un secondo pagamento.

“Pending” è diverso anche da “confirmed”, “finalized” o “failed”. L’hash di una transazione può essere visibile prima che esista una receipt; la receipt diventa disponibile dopo l’inclusione in un blocco. I blocchi Ethereum attraversano poi diverse fasi di consenso. Wallet ed explorer possono usare queste etichette in modo diverso: controlla quindi l’hash, il blocco, la receipt e lo stato attuale della catena, invece di basarti su una sola etichetta sintetica.

Un normale account Ethereum controllato esternamente (externally owned account, EOA) ha un nonce che ordina le sue transazioni. Il nonce è un contatore, non una commissione, un timestamp o un hash univoco della transazione. Per ogni account, la catena accetta una transazione soltanto se usa il nonce successivo previsto dallo stato dell’account. Sulla catena canonica lo stesso account non può eseguire due transazioni con lo stesso nonce. La documentazione sugli account di Ethereum.org descrive il nonce come contatore delle transazioni dell’account e meccanismo di protezione dai replay.

Supponiamo che il prossimo nonce non ancora usato da un account sia 41. La sua prossima transazione valida usa il nonce 41; dopo l’inclusione e l’applicazione di quella transazione, la successiva usa il nonce 42. Il nonce è associato all’account mittente, non all’indirizzo di destinazione. Due account diversi possono avere entrambi una transazione numerata 41 nello stesso momento, perché ciascuno ha la propria sequenza.

Una transazione può essere firmata con un nonce superiore al nonce attuale dell’account sulla catena, ma non può saltare la sequenza quando viene eseguita. Prima deve essere consumato il nonce precedente mancante. Una transazione con un nonce già consumato dall’account è obsoleta e non può essere eseguita come nuova transazione. Questo ordine permette alla rete di elaborare in sequenza le transazioni di ogni account, anche se vengono trasmesse in momenti diversi o arrivano attraverso nodi diversi.

La regola del nonce vale per le normali transazioni EOA sul livello di esecuzione di Ethereum. Non descrive in modo universale ogni astrazione del wallet, sequencer di rollup o blockchain. I sistemi con smart account possono aggiungere le proprie regole per operazioni e nonce, come vedremo più avanti.

Ethereum non ha un’unica sala d’attesa sincronizzata che ogni wallet, nodo, explorer e proponente vede esattamente allo stesso modo. Ogni client di esecuzione mantiene un pool locale di transazioni ricevute che considera idonee secondo i propri limiti e criteri. Una transazione può comparire nel pool di un nodo ma non in quello di un altro. La documentazione RPC di txpool di Geth espone i gruppi locali pending e queued di quel client e segnala che più transazioni possono essere associate allo stesso mittente e nonce.

Nella terminologia di Geth, pending indica in genere transazioni elaborabili in ordine di nonce dallo stato attuale dell’account; queued può includere transazioni con nonce futuri in attesa che si chiuda un gap. Questi nomi descrivono un’interfaccia del client, non stati di consenso che tutti i software Ethereum devono mostrare. Un wallet può chiamare “pending” l’intero elenco delle transazioni non confermate, mentre un explorer può mostrare solo quelle osservate dai propri fornitori di dati.

Per esempio, se un nodo conosce una transazione con nonce 41 e un’altra con nonce 43, non può eseguire la 43 prima della 42. Potrebbe mantenere la 43 in coda finché non arriva la 42 o l’account avanza in un altro modo. Un altro nodo che non ha mai ricevuto la 43 non la mostrerà affatto. Ecco perché due explorer possono non concordare sul fatto che una transazione sia pending o assente, senza che nessuna delle due schermate provi cosa abbiano visto tutti i validatori.

Alcuni client consentono anche più di una transazione candidata non confermata per lo stesso mittente e nonce. Sono alternative concorrenti per lo stesso slot della sequenza, non due transazioni che possono essere applicate entrambe in ordine. Capacità del pool, durata delle transazioni e regole di sostituzione sono criteri di implementazione che possono cambiare tra versioni software. Per esempio, le opzioni configurabili del pool di transazioni di Geth includono una soglia di aumento del prezzo specifica del client; non va considerata una regola universale sulle commissioni Ethereum. Consulta la documentazione della riga di comando di Geth per l’ambito di queste opzioni.

Immagina che il prossimo nonce on-chain dell’account sia 41. Trasmetti la transazione A con nonce 41 e poi la transazione B con nonce 42. Se A è ancora irrisolta, B non può essere applicata prima. B può restare in una coda locale, comparire come pending solo nel wallet o non essere visibile in un explorer che non l’ha ricevuta. Conta il rapporto tra i nonce, non l’ordine in cui il wallet ha creato o mostrato le due transazioni.

Se A viene infine inclusa, il nonce dell’account avanza a 42 e B può diventare idonea, in base alla sua validità, alle condizioni delle commissioni e ai criteri del pool. Se A viene sostituita da un’altra transazione valida con nonce 41, la sostituzione occupa la stessa posizione nella sequenza se è quella inclusa. Se un’altra transazione dell’account ha consumato il nonce 41, il vecchio candidato con nonce 41 è obsoleto e non può più essere eseguito.

Ecco perché inviare una nuova transazione con un nonce più alto non è un metodo generale per sbloccare una transazione. Aggiunge un’altra transazione dopo il gap. Annullare B non risolve A se B ha già un nonce successivo. Parti dal nonce irrisolto più basso dell’account e verificane lo stato prima di intervenire.

Un gap può essere temporaneo o persistente. La transazione precedente potrebbe non essere arrivata al nodo che stai controllando, le sue impostazioni delle commissioni potrebbero risultare poco allettanti o insufficienti nelle condizioni attuali, oppure potrebbe essere stata rimossa dal pool di un nodo. Il wallet può anche mostrare una transazione queued creata su un altro dispositivo. La schermata da sola non rivela quale situazione si sia verificata: confronta il nonce confermato dell’account, gli hash delle transazioni e più di una fonte affidabile.

L’ordine dei nonce e l’idoneità delle commissioni sono vincoli distinti. Una transazione con il nonce successivo corretto può comunque attendere se i suoi parametri di commissione non soddisfano le condizioni per un blocco. Una transazione con nonce più alto non può saltare la fila solo offrendo una mancia maggiore. Aumentare la commissione del nonce 42 non fa sparire il nonce 41.

Per una normale transazione EIP-1559, la commissione massima deve poter coprire la base fee del blocco che la include e la priority fee può influenzare la scelta del proponente del blocco. Sia la base fee sia lo spazio disponibile nel blocco possono cambiare durante l’attesa. La commissione massima è un tetto; un tetto più alto non garantisce uno specifico tempo di conferma. La guida alle commissioni gas di Ethereum spiega questi campi e il calcolo della commissione effettiva.

Un nodo o un wallet può applicare ulteriori regole di inoltro o sostituzione. Questi criteri determinano cosa quello specifico servizio è disposto ad accettare o inoltrare; non sono tutti regole di consenso. Per esempio, Geth espone una soglia configurabile di aumento del prezzo per sostituire una transazione pending nel proprio pool. Un altro client, provider, wallet o versione software può comportarsi diversamente. Non fare affidamento su una percentuale ricordata o su un tempo di attesa fisso come garanzia valida per tutta la rete.

Se la transazione è in attesa perché un nonce inferiore non è risolto, individua prima la transazione che occupa quel nonce. Se è in attesa perché il tetto della commissione non copre le condizioni attuali della base fee, comprendi i campi di commissione prima di modificarli. La guida alle commissioni Ethereum è il riferimento per i calcoli; questo articolo riguarda il distinto problema dell’ordine.

La funzione “accelera” di un wallet in genere prepara una nuova transazione dallo stesso account con lo stesso nonce e parametri di commissione modificati. I due candidati sono in conflitto perché l’account può eseguire una sola transazione per quel nonce. Se la sostituzione viene accettata nei pool pertinenti e inclusa, può occupare lo slot del nonce; la transazione originale non potrà più essere eseguita sulla catena canonica. Le istruzioni di MetaMask sulle transazioni pending descrivono la propria funzione di accelerazione come un nuovo invio con lo stesso nonce e una commissione maggiore.

La sostituzione può mantenere destinazione e azione originali modificando i campi delle commissioni, ma controlla la schermata di firma invece di dare per scontato che sia così. Un wallet può mostrare altri campi o assegnare un’etichetta diversa all’azione. Prima di firmare, verifica account mittente, nonce, destinatario, valore e dati del contratto. Se la sostituzione cambia ciò che fa la transazione, non si tratta soltanto di un innocuo adeguamento della commissione.

Non è garantito che la sostituzione venga accettata ovunque o inclusa rapidamente. La transazione originale potrebbe essere già stata inclusa; un nodo potrebbe rifiutare la sostituzione secondo i propri criteri; il proponente potrebbe continuare a non trovarla conveniente; oppure il servizio potrebbe non inoltrarla ai nodi che stai monitorando. Se l’originale è già confermata, inviare un’altra transazione con quel nonce già consumato non può annullarla e di solito viene rifiutato come obsoleto.

Qui “sostituzione” significa una transazione concorrente dallo stesso account e con lo stesso nonce. Non applicare a Ethereum le procedure Bitcoin RBF o CPFP: Bitcoin usa un modello di transazione diverso e i suoi meccanismi per aumentare le commissioni non sono istruzioni per gli account Ethereum.

Dopo che una transazione Ethereum firmata è stata trasmessa, non esiste un comando di annullamento a livello di protocollo che la ritiri da ogni nodo. Alcuni wallet offrono un’azione di annullamento finché la transazione non è confermata. In genere l’azione tenta di pubblicare una transazione diversa dallo stesso account con lo stesso nonce; uno schema comune è una transazione di valore zero verso il proprio indirizzo. Se il candidato di annullamento viene accettato e incluso prima dell’originale, consuma il nonce e rende l’originale non più eseguibile in seguito. Costruzione e disponibilità esatte dipendono dal wallet.

La transazione originale e il candidato di annullamento possono fare a gara. Se l’originale viene inclusa per prima, un annullamento inviato dopo non può annullarne gli effetti. Se nessuno dei due candidati viene accettato o incluso, il nonce può restare irrisolto. Il clic sul pulsante del wallet o un messaggio di esito positivo non prova che l’annullamento abbia vinto. Controlla l’hash risultante e lo stato sulla catena canonica. Le istruzioni di MetaMask limitano esplicitamente il tentativo di annullamento a una transazione ancora pending e spiegano che una transazione confermata non può essere annullata.

Prima di firmare una transazione di annullamento, controlla che usi lo stesso account e nonce della transazione che vuoi sostituire e ispeziona ogni campo mostrato dal wallet. Se viene inclusa, potrebbe richiedere un’altra commissione di rete. Anche il candidato di annullamento può restare in attesa o non riuscire a sostituire l’originale secondo i criteri dei pool pertinenti. La parola “annullata” nel wallet non prova un’inversione a livello di protocollo: considera verificato il risultato solo dopo aver controllato quale transazione ha consumato il nonce.

Se la transazione ha già eseguito un’approvazione di token, una chiamata a un contratto o un trasferimento, annullare una transazione successiva non può invertire la modifica di stato già completata. Alcune operazioni dei contratti hanno metodi successivi separati, ma disponibilità ed effetti dipendono dal contratto. Non firmare una transazione sconosciuta solo perché l’interfaccia la chiama annullamento.

Una transazione inclusa ha un blocco e una receipt. Se ha esito positivo, le modifiche di stato previste potrebbero essere state applicate. Se l’esecuzione EVM subisce un revert, le modifiche di stato di quell’esecuzione vengono annullate, ma la transazione ha comunque consumato il nonce dell’account e può comportare un costo in gas. Usa la receipt e lo stato di esecuzione, invece di dedurre il successo da una notifica del wallet. Consulta la guida alle transazioni Ethereum e la guida al gas per distinguere inclusione ed esito dell’esecuzione.

L’etichetta “dropped” o “not found” spesso è una segnalazione di un singolo wallet, explorer, provider RPC o pool locale. Da sola non prova che il protocollo abbia annullato la transazione o che il suo nonce sia libero. Un altro nodo potrebbe ancora conoscerla; il wallet potrebbe ritrasmettere la transazione firmata; oppure un blocco successivo potrebbe mostrare che il nonce dell’account è già avanzato. Al contrario, una transazione vecchia può essere assente dalle viste controllate mentre il nonce confermato dell’account non è cambiato.

Se l’hash della transazione non viene trovato, verifica di aver selezionato la stessa catena e lo stesso account che l’hanno generato. Confronta il nonce on-chain più recente dell’account con quello della transazione ed esamina le transazioni recenti di quel mittente. Una risposta nonce too low suggerisce che il nonce potrebbe essere già stato consumato secondo la prospettiva dell’endpoint; non è un motivo per ripetere la stessa richiesta. Verifica quale transazione lo ha usato e se il blocco è ancora canonico.

Una transazione inclusa può anche essere coinvolta in una breve riorganizzazione della catena prima che questa si stabilizzi. Wallet ed explorer possono aggiornare le etichette quando cambia la loro visuale. Per un trasferimento importante, attendi secondo la politica di conferma del servizio ricevente e, se pertinente, una finalità di consenso più forte: “vista in un blocco” e “irreversibile in ogni circostanza” non sono affermazioni equivalenti.

Per prima cosa conferma la catena, l’account mittente e l’hash della transazione. Cerca l’hash su un explorer affidabile per la rete corretta. Controlla se esiste una receipt, quale nonce usa, se l’esecuzione è riuscita e se l’account ha effettuato una transazione successiva. Non rivelare né inserire la seed phrase per controllare una transazione: per consultare una blockchain pubblica bastano un indirizzo pubblico e l’hash della transazione.

Se l’hash non è visibile, confronta il nonce confermato più recente dell’account con quello indicato dal wallet. Uno sviluppatore o un operatore di nodo può interrogare eth_getTransactionCount usando i tag di blocco latest e pending. La documentazione JSON-RPC di Ethereum.org definisce questi tag: latest si riferisce allo stato dell’ultimo blocco, mentre pending si riferisce allo stato pending. Il risultato pending dipende comunque dalla vista dell’endpoint RPC; due provider possono restituire valori diversi. La maggior parte degli utenti può ottenere gli stessi primi indizi dall’attività dell’account nel wallet e da un explorer affidabile senza eseguire comandi.

Poi parti dal nonce più basso che non è stato consumato. Se la transazione originale è ancora visibile e il wallet supporta la sostituzione, controlla i campi esatti e le commissioni della sostituzione prima di firmarla. Se non è visibile, chiedi al wallet o al provider RPC come gestisce invii ripetuti e sostituzioni invece di presumere che la transazione sia sparita dalla rete. Se il nonce è già consumato, identifica la transazione inclusa prima di fare altro. Evita di inviare ripetutamente nuove transazioni con nonce successivi: potresti allungare la coda senza risolvere il primo gap.

Questi passaggi riguardano le normali transazioni di account esterni Ethereum. I sistemi di account abstraction possono inviare UserOperation tramite bundler e gli smart account possono usare chiavi e sequenze di nonce più articolate di un unico contatore. EIP-4337 definisce una struttura nonce per queste operazioni, perciò un wallet con account abstraction può comportarsi diversamente dagli esempi EOA di questo articolo. Per reti di destinazione, indirizzi e stato dei trasferimenti, consulta la checklist per i trasferimenti crypto.