---
title: "Mempool e pool di transazioni"
description: "Guida al carattere locale dell'ammissione delle transazioni Ethereum, nonce pending e in coda, propagazione, idoneità delle commissioni, sostituzione, flusso privato, inclusione, rimozione e riorganizzazione."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Mempool e pool di transazioni
> Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.
## Risposta diretta
Una mempool, o pool di transazioni, è l'insieme temporaneo, conservato in memoria e talvolta persistente, delle transazioni firmate che un nodo ha accettato secondo le proprie regole correnti di validazione e policy, ma che non sono nella sua chain canonica. Non è un oggetto di consenso, una coda globale o una promessa di inclusione. Due nodi onesti possono contenere transazioni diverse perché hanno ricevuto gossip differente, eseguono client o configurazioni diverse, sono stati riavviati, hanno rimosso elementi o usano percorsi pubblici e privati differenti.
In un execution client Ethereum, una transazione eseguibile con il successivo `nonce` dell'account è comunemente definita pending; un nonce successivo bloccato da un gap è comunemente definito in coda. Queste sono etichette delle interfacce client, non stati finali del protocollo. Una transazione può essere rifiutata prima dell'ammissione, propagata, sostituita da un'altra transazione firmata con lo stesso mittente e nonce, rimossa, scartata, inclusa con successo, inclusa e soggetta a revert o riconsiderata dopo una riorganizzazione.
## Come funziona
1. Fissare l'ambiente: chain ID, execution client e versione, head e base fee correnti, tipo di transazione, mittente, nonce, valore, calldata, gas limit, massimali di commissione e percorso di invio. Distinguere gossip pubblico, relay o builder privato e percorso ERC-4337 di `UserOperation`; non condividono un pool universale.
2. Decodificare i byte firmati ed eseguire i controlli precedenti all'ammissione. Verificare firma e mittente, chain ID, tipo e codifica, gas intrinseco, relazione del nonce, saldo per valore più esposizione massima alle commissioni, campi delle commissioni ed eventuale sidecar del blob richiesto. Un rifiuto in questa fase non è un `REVERT` EVM e normalmente non genera receipt o commissioni onchain.
3. Mappare la policy locale del pool. Registrare se il client classifica la transazione come pending o in coda, capacità per account e globale, filtri minimi sulle commissioni, durata, esenzioni per account locali, incremento per la sostituzione e persistenza. Flag e impostazioni predefinite di Geth documentano Geth, non il consenso Ethereum o tutti i provider.
4. Osservare la propagazione senza inventare una vista globale. Confrontare hash e byte firmati della transazione raw tra nodi indipendenti, ma considerare ambigua l'assenza: il nodo potrebbe non averla ricevuta, rifiutarla per policy locale, averla rimossa o non esporre il proprio pool. Un percorso privato può evitare il gossip pubblico pur condividendo la transazione con operatori e builder.
5. Modellare idoneità e ordinamento nel blocco candidato. Per una transazione di tipo 2, il prezzo del gas di esecuzione è `min(maxFeePerGas, baseFeePerGas + maxPriorityFeePerGas)`; se la base fee supera la commissione massima, la transazione non è idonea sotto tale limite. Dipendenze di nonce, limiti gas e blob, validità dello stato, bundle dei builder e MEV possono contare più dell'ordine di ricezione.
6. Gestire deliberatamente il ciclo di vita. Attendere o inviare una sostituzione documentata con lo stesso nonce solo dopo aver confermato chain attiva, mittente e policy di sostituzione. Un trasferimento a sé stessi con lo stesso nonce è soltanto un altro candidato sostitutivo, non una primitiva di annullamento. Non ripetere un trasferimento di valore perché un explorer non mostra più l'originale.
7. Riconciliare con lo stato di consenso. Conservare ogni hash firmato e la sequenza delle sostituzioni, quindi controllare receipt canonica, hash del blocco, stato, gas usato, log, nonce consumato e stato dell'account o contratto al livello richiesto di conferma o finalità. Se una riorganizzazione rimuove il blocco, una transazione ancora valida può tornare in alcuni pool locali, ma dipende dal client e dallo stato.
## Esempi svolti
- **Idoneità rispetto al limite di commissione.** Un trasferimento di tipo 2 presenta `gasUsed = 21,000`, `baseFeePerGas = 32 gwei`, `maxPriorityFeePerGas = 3 gwei` e `maxFeePerGas = 34 gwei`. Il prezzo effettivo è `min(34, 32 + 3) = 34 gwei`, quindi la mancia reale è `2 gwei`. La commissione è `21,000 * 34 = 714,000 gwei = 0.000714 ETH`, suddivisa in `0.000672 ETH` di base fee bruciata e `0.000042 ETH` di mancia. Se la base fee del blocco candidato sale a `35 gwei`, il limite di `34 gwei` non basta per quel blocco.
- **Gap di nonce.** Il nonce canonico dell'account è `10`. Un pool locale riceve transazioni con nonce `10` e `12`, ma nessuna con `11`; può classificare `10` come pending e `12` come in coda. Dopo l'inclusione del nonce `10`, il nonce canonico diventa `11`, mentre `12` resta bloccato finché non viene inclusa una transazione valida con nonce `11`. La presenza del nonce `12` nel pool non lo rende eseguibile autonomamente.
- **Sostituzione specifica della policy.** In una configurazione didattica Geth con `txpool.pricebump = 10`, una vecchia transazione ha `maxFeePerGas = 40 gwei` e `maxPriorityFeePerGas = 2 gwei`. Un incremento del 10% produce soglie di `44 gwei` e `2.2 gwei`. Una proposta con `43 gwei` e `3 gwei` può essere comunque rifiutata perché un limite non raggiunge l'incremento configurato; `44 gwei` e `2.2 gwei` raggiungono entrambe le soglie didattiche. Arrotondamento intero, tipo di transazione e logica di accettazione esatti dipendono dalla versione; un altro nodo può conservare un candidato diverso.
- **Nessun pool globale.** Il nodo A segnala `120,000` hash distinti, il nodo B `100,000`, con un'intersezione di `80,000`. L'unione è `120,000 + 100,000 - 80,000 = 140,000`; la sovrapposizione di Jaccard è `80,000 / 140,000 = 57.1428571429%`. `40,000` hash sono visibili solo ad A e `20,000` solo a B. Nessun conteggio prova ciò che possono vedere un builder, un relay privato o il resto della rete.
## Rischi
- Firmare o trasmettere sulla chain ID o rete errata.
- Fidarsi di endpoint RPC malevolo, obsoleto o configurato male.
- Firma, tipo di transazione, codifica o sidecar del blob non validi.
- Saldo insufficiente per valore più esposizione massima alle commissioni.
- Rifiuto pre-ammissione dovuto alle regole su gas intrinseco o calldata.
- Nonce già consumato o troppo basso.
- Gap di nonce che lascia in coda le transazioni successive.
- Sostituzione con stesso nonce rifiutata come sottoprezzata dalla policy locale.
- Commissione massima sotto la base fee del blocco candidato.
- Priorità effettiva bassa o vincoli di risorse che ritardano l'inclusione.
- Disallineamento di policy tra client, provider, versione o configurazione.
- Capacità, scadenza, riavvio o rimozione dal pool elimina la transazione.
- Cattiva propagazione, eclipse o comportamento selettivo del relay.
- Perdita di dati, censura, indisponibilità o mancata partecipazione dei builder nel relay privato.
- Frontrunning, sandwich o altro MEV sul flusso pubblico.
- Riordino dei builder, bundle o transazioni private che modificano lo stato.
- Simulazione che diventa obsoleta prima dell'inclusione.
- Invio duplicato alla cieca o perdita della sequenza di sostituzione.
- `REVERT` incluso, out of gas o errore di sott chiamata intercettato nonostante l'ammissione.
- Riorganizzazione, confusione sulla finalità o mempool ERC-4337 trattato come txpool ordinario.
## Errori comuni
- La mempool è un'unica coda FIFO sincronizzata globalmente.
- Un hash dimostra che la rete ha accettato o propagato la transazione.
- Pending significa inclusa, riuscita, irreversibile o pagata al destinatario.
- Una commissione sufficientemente alta garantisce inclusione ed esecuzione riuscita.
- Un percorso privato è automaticamente riservato, resistente alla censura e garantito.
## Argomenti correlati
- [Commissioni gas](/it/crypto/gas-fee/)
- [Sostituzione nella mempool](/it/crypto/mempool-replacement/)
- [MEV](/it/crypto/mev/)
## Fonti
- [Transactions](https://ethereum.org/developers/docs/transactions/) - Ethereum.org (consultato il: 2026-08-13)
- [EIP-1559: Fee market change for ETH 1.0 chain](https://eips.ethereum.org/EIPS/eip-1559) - Ethereum Improvement Proposals (consultato il: 2026-08-13)
- [txpool Namespace](https://geth.ethereum.org/docs/interacting-with-geth/rpc/ns-txpool) - go-ethereum (consultato il: 2026-08-13)
- [Command-line Options](https://geth.ethereum.org/docs/fundamentals/command-line-options) - go-ethereum (consultato il: 2026-08-13)
- [JSON-RPC API](https://ethereum.org/developers/docs/apis/json-rpc/) - Ethereum.org (consultato il: 2026-08-13)
- [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) - Ethereum Improvement Proposals (consultato il: 2026-08-13)
- [ERC-4337: Account Abstraction Using Alt Mempool](https://eips.ethereum.org/EIPS/eip-4337) - Ethereum Improvement Proposals (consultato il: 2026-08-13)
- [MEV Protection Overview](https://docs.flashbots.net/flashbots-protect/overview) - Flashbots Documentation (consultato il: 2026-08-13)
Source: https://wiki.fcontext.com/it/crypto/mempool/index.mdx