Vai al contenuto
Financial Context Wiki

Sostituzione delle transazioni nel mempool di Ethereum

Guida specifica per client alla sostituzione di transazioni Ethereum dello stesso mittente e con lo stesso nonce, agli aumenti dei massimali di commissione, alle corse di annullamento, alle transazioni blob, alle rotte private, alle ricevute e alla finalità.

Aggiornato

Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.

Risposta diretta

La sostituzione di una transazione Ethereum è una politica locale del pool di transazioni in base alla quale un nodo può preferire una nuova transazione firmata rispetto a un’altra candidata dello stesso mittente e con lo stesso nonce. Non è un interruttore Replace-by-Fee globale a livello di consenso. L’accettazione del nuovo hash da parte di un nodo non cancella la vecchia transazione firmata dagli altri nodi, relay privati o builder; soltanto l’inclusione canonica determina quale candidata consuma il nonce dell’account.

La funzione Accelera di un wallet conserva normalmente destinazione, valore e calldata originali, aumentando i campi di commissione. Un Annullamento nel pool pubblico crea normalmente un trasferimento a sé stessi di valore zero con lo stesso mittente e nonce. È una transazione concorrente, non un’operazione di ripristino: se viene inclusa prima l’originale, il relativo trasferimento o la chiamata al contratto non vengono annullati. Le rotte private specifiche di un prodotto possono definire API di annullamento differenti; per esempio, Flashbots Protect documenta un annullamento autenticato che non viene pubblicato onchain e che non va generalizzato alla sostituzione pubblica delle transazioni Ethereum.

Come funziona

  1. Fissare la lineage esatta: chain ID, client e versione, blocco di testa e base fee, rotta di invio, mittente, nonce canonico dell’account, byte grezzi firmati, hash e tipo della transazione originale. Interrogare più viste pubbliche o private pertinenti; l’etichetta di un wallet o una singola risposta RPC non rappresentano lo stato globale.
  2. Classificare correttamente l’originale come rifiutata, pending localmente, in coda dietro un gap di nonce, scartata o rimossa, inviata privatamente, inclusa con successo, inclusa con status = 0, rimossa da una riorganizzazione o finalizzata. Non considerare più disponibile la sostituzione quando il nonce è stato consumato canonicamente, anche se una riorganizzazione può riaprire la corsa.
  3. Definire la nuova intenzione. Un’accelerazione deve riprodurre ogni campo semantico previsto; un tentativo pubblico di annullamento utilizza normalmente lo stesso mittente e nonce con to = sender, value = 0 e calldata vuoti. Prima di firmare, confrontare chain ID, tipo, destinazione, valore, calldata, access list, gas limit, hash dei blob e autorizzazione.
  4. Consultare l’effettiva politica di sostituzione del nodo destinatario. Le transazioni legacy e di tipo 1 usano gasPrice; quelle di tipo 2 espongono maxFeePerGas e maxPriorityFeePerGas; quelle di tipo 3 espongono anche maxFeePerBlobGas e richiedono il sidecar. Gli attuali valori predefiniti Geth txpool.pricebump = 10 e blobpool.pricebump = 100 sono esempi di configurazione Geth, non costanti valide per l’intera rete Ethereum.
  5. Calcolare separatamente l’idoneità e la copertura finanziaria dell’aumento. Per il tipo 2, il prezzo effettivo è min(maxFeePerGas, baseFeePerGas + maxPriorityFeePerGas). La candidata richiede inoltre codifica valida, gas intrinseco sufficiente e saldo per coprire valore ed esposizione massima alle commissioni; un massimale più elevato non corregge calldata non validi né garantisce l’esecuzione EVM con successo.
  6. Inviare deliberatamente e conservare ogni risposta. La ritrasmissione pubblica può rivelare l’intenzione ed esporla al MEV; i relay privati hanno visibilità, annullamento, copertura dei builder e disponibilità propri. Tracciare hash vecchio e nuovo su ogni rotta senza presumere che l’accettazione locale abbia eliminato la concorrente e senza inviare alla cieca una terza candidata che trasferisca valore.
  7. Riconciliare la vincitrice sulla chain canonica. Verificare blocco e hash della ricevuta, indice della transazione, status, gas utilizzato, prezzo effettivo del gas, log, nonce del mittente, saldi e stato del contratto al livello di finalità richiesto. Registrare gli hash perdenti come sostituiti, scartati o ancora osservati in base alle evidenze e ripetere l’analisi dopo una riorganizzazione.

Esempi svolti

  • Aumento didattico di una normale transazione di tipo 2. Una vecchia candidata ha maxFeePerGas = 40 gwei e maxPriorityFeePerGas = 2 gwei. Con una configurazione didattica Geth che prevede un aumento del 10%, le soglie aritmetiche sono 44 gwei e 2.2 gwei. Una candidata a 44/2.1 gwei non raggiunge la soglia della mancia; 44/2.2 gwei raggiunge entrambe le soglie didattiche. Con una base fee di 32 gwei e 21,000 unità di gas utilizzate, il prezzo effettivo è 34.2 gwei, la commissione totale è 718,200 gwei = 0.0007182 ETH, il base burn è 0.000672 ETH e la mancia è 0.0000462 ETH. L’accettazione effettiva dipende da implementazione, versione e arrotondamento a wei interi.
  • Sensibilità alla base fee. Una sostituzione ha massimali 66/4.4 gwei. Con una base fee di 60 gwei, il prezzo effettivo è min(66, 60 + 4.4) = 64.4 gwei. Con una base fee di 65 gwei, il prezzo effettivo è 66 gwei e la mancia effettiva è solo 1 gwei. Con una base fee di 67 gwei, vale 66 < 67, quindi la candidata non è idonea con quel massimale, anche se ha superato una verifica locale dell’aumento.
  • Corsa di annullamento. La transazione originale con nonce 20 invia 5 ETH a un commerciante. Se vince a 21,000 * 42 gwei = 0.000882 ETH, il commerciante riceve 5 ETH e l’annullamento ha poi un nonce troppo basso. Se vince il trasferimento a sé stessi di valore zero a 21,000 * 45 gwei = 0.000945 ETH, consuma il nonce 20 e impedisce all’originale di entrare successivamente nella stessa storia canonica. Nessuno dei due risultati è deducibile dal solo clic su Annulla.
  • Confine del blob pool. Una vecchia candidata di tipo 3 ha massimale della commissione di esecuzione 100 gwei, massimale della mancia 3 gwei e massimale della commissione blob 20 gwei. Con una configurazione didattica del blob pool Geth che prevede un aumento del 100%, le soglie aritmetiche sono 200/6/40 gwei. Una candidata a 200/6/39 gwei non raggiunge il massimale blob; 200/6/40 gwei raggiunge tutte e tre le soglie didattiche, ma richiede comunque sidecar, nonce, saldo e ammissione al pool validi. Questi valori non sono regole per transazioni normali o altri client.

Rischi

  • Selezione del chain ID o della rete errati.
  • Selezione del mittente o del nonce dell’account errati.
  • Utilizzo di blocco di testa, base fee o nonce canonico non aggiornati.
  • Tentativo di sostituzione dopo l’inclusione o la finalizzazione dell’originale.
  • Applicazione delle regole del txpool ordinario a una UserOperation ERC-4337.
  • Presunzione che un altro client, provider, versione o configurazione utilizzi la stessa politica.
  • Mancato raggiungimento della soglia di aumento a causa dell’arrotondamento a wei interi.
  • Aumento di un solo campo di commissione richiesto da EIP-1559.
  • Impostazione di maxFeePerGas sotto la base fee del blocco candidato.
  • Omissione del massimale della commissione blob, del sidecar o di una regola speciale del blob pool.
  • Saldo insufficiente per valore e commissioni massime autorizzate.
  • Firma, tipo, codifica, gas intrinseco o dominio della chain non validi.
  • Modifica involontaria di destinazione, valore, calldata, access list o hash dei blob.
  • Perdita della corsa di inclusione da parte di una transazione pubblica di annullamento.
  • Permanenza della vecchia transazione presso altri nodi o negli input dei builder.
  • Perdita di riservatezza, censura, scarto o mancato annullamento dell’invio da parte di un relay privato.
  • Esposizione dell’intenzione a frontrunning, sandwiching o altro MEV tramite ritrasmissione pubblica.
  • Blocco delle transazioni successive per un gap di nonce o induzione di un trasferimento duplicato.
  • Inclusione della sostituzione con successivo revert o esaurimento del gas, consumando nonce e commissioni.
  • Riattivazione o classificazione errata delle candidate per errori di riorganizzazione, finalità o lineage delle ricevute.

Falsi miti comuni

  • Una candidata con una commissione maggiore cancella globalmente la vecchia transazione.
  • Due transazioni con lo stesso nonce numerico si sostituiscono anche se hanno mittenti differenti.
  • Il pulsante Annulla di un wallet revoca una transazione già inclusa.
  • L’accettazione della sostituzione da parte di un nodo dimostra che i builder la includeranno.
  • Una regola universale di aumento del 10% copre ogni client, transazione blob, relay privato e UserOperation.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...