Ir para o conteúdo
Financial Context Wiki

Substituição de transações no mempool do Ethereum

Guia específico por cliente sobre substituição de transações Ethereum do mesmo remetente e nonce, aumentos dos limites de comissão, corridas de cancelamento, transações blob, rotas privadas, recibos e finalidade.

Atualizado

Somente para fins educacionais; não constitui recomendação nem aconselhamento de investimento. Investir pode causar perdas.

Resposta direta

A substituição de uma transação Ethereum é uma política local do pool de transações pela qual um nó pode preferir uma transação recém-assinada a outra candidata do mesmo remetente e com o mesmo nonce. Não é um mecanismo global de Replace-by-Fee no nível de consenso. A aceitação do novo hash por um nó não apaga a transação assinada anterior de outros nós, relays privados ou builders; somente a inclusão canônica determina qual candidata consome o nonce da conta.

A ação Acelerar de uma carteira normalmente preserva destino, valor e calldata originais e eleva os campos de comissão. Um Cancelamento no pool público normalmente cria uma transferência de valor zero para a própria conta, com o mesmo remetente e nonce. Trata-se de uma transação concorrente, não de uma operação de desfazer: se a original for incluída primeiro, sua transferência ou chamada de contrato não será revertida. Rotas privadas específicas podem definir outras APIs de cancelamento; por exemplo, o Flashbots Protect documenta um cancelamento autenticado que não é publicado onchain e que não deve ser generalizado para a substituição pública de transações Ethereum.

Como funciona

  1. Fixe a linhagem exata: chain ID, cliente e versão, bloco de ponta e base fee, rota de envio, remetente, nonce canônico da conta, bytes brutos assinados, hash e tipo da transação original. Consulte várias visões públicas ou privadas relevantes; um rótulo da carteira ou uma única resposta RPC não representa o estado global.
  2. Classifique corretamente a original como rejeitada, pendente localmente, em fila atrás de uma lacuna de nonce, descartada ou removida, enviada em particular, incluída com sucesso, incluída com status = 0, removida por uma reorganização ou finalizada. Pare de considerar a substituição disponível quando o nonce tiver sido consumido canonicamente, embora uma reorganização possa reabrir a corrida.
  3. Defina a nova intenção. Uma aceleração deve reproduzir todos os campos semânticos pretendidos; uma tentativa pública de cancelamento normalmente usa o mesmo remetente e nonce com to = sender, value = 0 e calldata vazio. Compare chain ID, tipo, destino, valor, calldata, lista de acesso, limite de gas, hashes de blob e autorização antes de assinar.
  4. Consulte a política real de substituição do nó de destino. Transações legacy e tipo 1 usam gasPrice; as de tipo 2 expõem maxFeePerGas e maxPriorityFeePerGas; as de tipo 3 também expõem maxFeePerBlobGas e exigem o sidecar. Os padrões atuais do Geth txpool.pricebump = 10 e blobpool.pricebump = 100 são exemplos de configuração do Geth, não constantes do Ethereum.
  5. Calcule separadamente a elegibilidade e o financiamento do aumento. Para o tipo 2, o preço efetivo é min(maxFeePerGas, baseFeePerGas + maxPriorityFeePerGas). A candidata também precisa de codificação válida, gas intrínseco suficiente e saldo para cobrir o valor mais a exposição máxima a comissões; um limite maior não corrige calldata inválido nem garante execução bem-sucedida pela EVM.
  6. Envie deliberadamente e preserve cada resposta. A retransmissão pública pode revelar a intenção e expô-la a MEV; relays privados têm visibilidade, cancelamento, cobertura de builders e disponibilidade próprios. Acompanhe os hashes antigo e novo em cada rota sem supor que a aceitação local eliminou a concorrente ou enviar às cegas uma terceira candidata que transfira valor.
  7. Reconcilie a vencedora na cadeia canônica. Verifique bloco e hash do recibo, índice da transação, status, gas usado, preço efetivo do gas, logs, nonce do remetente, saldos e estado do contrato no nível de finalidade exigido. Registre os hashes perdedores como substituídos, descartados ou ainda observados conforme a evidência e reinicie a análise após uma reorganização.

Exemplos resolvidos

  • Aumento didático de uma transação comum tipo 2. Uma candidata antiga tem maxFeePerGas = 40 gwei e maxPriorityFeePerGas = 2 gwei. Em uma configuração didática do Geth com aumento de 10%, os limiares aritméticos são 44 gwei e 2.2 gwei. Uma candidata de 44/2.1 gwei não atinge o limiar da gorjeta; 44/2.2 gwei atinge ambos os limiares didáticos. Com base fee de 32 gwei e 21,000 unidades de gas usadas, o preço efetivo é 34.2 gwei, a comissão total é 718,200 gwei = 0.0007182 ETH, a queima base é 0.000672 ETH e a gorjeta é 0.0000462 ETH. A aceitação real depende da implementação, da versão e do arredondamento para wei inteiros.
  • Sensibilidade à base fee. Uma substituição tem limites 66/4.4 gwei. Com base fee de 60 gwei, o preço efetivo é min(66, 60 + 4.4) = 64.4 gwei. Com base fee de 65 gwei, o preço efetivo é 66 gwei e a gorjeta efetiva é apenas 1 gwei. Com base fee de 67 gwei, vale 66 < 67, portanto a candidata não é elegível sob esse limite, ainda que tenha satisfeito um teste local de aumento.
  • Corrida de cancelamento. A transação original de nonce 20 envia 5 ETH a um comerciante. Se vencer a 21,000 * 42 gwei = 0.000882 ETH, o comerciante recebe 5 ETH e o cancelamento fica com nonce baixo demais. Se a transferência de valor zero para a própria conta vencer a 21,000 * 45 gwei = 0.000945 ETH, ela consome o nonce 20 e impede a original de entrar posteriormente no mesmo histórico canônico. Nenhum resultado pode ser conhecido apenas ao clicar em Cancelar.
  • Limite do blob pool. Uma candidata antiga tipo 3 tem limite de comissão de execução de 100 gwei, limite de gorjeta de 3 gwei e limite de comissão de blob de 20 gwei. Em uma configuração didática do blob pool do Geth com aumento de 100%, os limiares aritméticos são 200/6/40 gwei. Uma candidata de 200/6/39 gwei não atinge o limite de blob; 200/6/40 gwei atinge os três limiares didáticos, mas ainda precisa de sidecar, nonce, saldo e admissão no pool válidos. Esses valores não são regras para transações comuns nem para outros clientes.

Riscos

  • Selecionar o chain ID ou a rede errados.
  • Selecionar o remetente ou nonce da conta errados.
  • Usar bloco de ponta, base fee ou nonce canônico desatualizados.
  • Tentar substituir depois que a original foi incluída ou finalizada.
  • Aplicar regras do txpool comum a uma UserOperation ERC-4337.
  • Supor que outro cliente, provedor, versão ou configuração usa a mesma política.
  • Não atingir o limiar de aumento por arredondamento para wei inteiros.
  • Elevar apenas um campo de comissão exigido pelo EIP-1559.
  • Definir maxFeePerGas abaixo da base fee do bloco candidato.
  • Ignorar limite de comissão de blob, sidecar ou regra específica do blob pool.
  • Não ter saldo para o valor mais as comissões máximas autorizadas.
  • Assinatura, tipo, codificação, gas intrínseco ou domínio de cadeia inválidos.
  • Alterar acidentalmente destino, valor, calldata, lista de acesso ou hashes de blob.
  • Uma transação pública de cancelamento perder a corrida de inclusão.
  • A transação antiga permanecer em outros nós ou entradas de builders.
  • Um relay privado vazar, censurar, descartar ou não cancelar o envio.
  • A retransmissão pública expor a intenção a frontrunning, sandwiching ou outro MEV.
  • Uma lacuna de nonce bloquear transações posteriores ou provocar transferência duplicada.
  • A substituição ser incluída, mas reverter ou esgotar o gas, consumindo nonce e comissões.
  • Erros de reorganização, finalidade ou linhagem de recibos reativarem ou classificarem mal as candidatas.

Equívocos comuns

  • Uma candidata com comissão maior apaga globalmente a transação antiga.
  • Duas transações com o mesmo nonce numérico se substituem mesmo com remetentes diferentes.
  • O botão Cancelar de uma carteira reverte uma transação já incluída.
  • A aceitação da substituição por um nó prova que os builders a incluirão.
  • Uma regra universal de aumento de 10% abrange todos os clientes, transações blob, relays privados e UserOperation.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...