Ir para o conteúdo
Financial Context Wiki

Mempools e pools de transações

Guia sobre o caráter local da admissão de transações Ethereum, nonces pendentes e em fila, propagação, elegibilidade por taxas, substituição, fluxo privado, inclusão, remoção e reorganização.

Atualizado

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

Resposta direta

Um mempool, ou pool de transações, é o conjunto temporário, mantido em memória e às vezes persistido, de transações assinadas que um nó aceitou segundo suas regras atuais de validação e política, mas que não estão em sua cadeia canônica. Não é objeto de consenso, fila global nem promessa de inclusão. Dois nós honestos podem conter transações diferentes porque receberam gossip distinto, executam clientes ou configurações diferentes, reiniciaram, removeram entradas ou usam rotas públicas e privadas distintas.

Em um cliente de execução Ethereum, uma transação executável com o próximo nonce da conta costuma ser chamada de pendente; um nonce posterior bloqueado por uma lacuna costuma ser chamado de em fila. Esses rótulos pertencem às interfaces dos clientes, não são estados finais do protocolo. Uma transação pode ser rejeitada antes da admissão, propagada, substituída por outra transação assinada do mesmo remetente e nonce, removida, descartada, incluída com sucesso, incluída e revertida ou reconsiderada após uma reorganização.

1
Criar

Uma carteira constrói uma transação com destino, valor, parâmetros de taxa e dados de proteção de reprodução, como entradas gastas ou um nonce.

Como funciona

  1. Fixe o ambiente: chain ID, cliente de execução e versão, head e taxa base atuais, tipo de transação, remetente, nonce, valor, calldata, limite de gas, tetos de taxa e rota de envio. Distinga gossip público, relay ou builder privado e uma rota ERC-4337 de UserOperation; eles não compartilham um pool universal.
  2. Decodifique os bytes assinados e faça verificações anteriores à admissão. Confira assinatura e remetente, chain ID, tipo e codificação, gas intrínseco, relação do nonce, saldo para valor mais exposição máxima a taxas, campos de taxa e qualquer sidecar de blob exigido. Uma rejeição aqui não é um REVERT da EVM e normalmente não cria recibo ou taxa onchain.
  3. Mapeie a política local do pool. Registre se o cliente classifica a transação como pendente ou em fila, capacidade por conta e global, filtros mínimos de taxa, vida útil, exceções para contas locais, incremento de substituição e persistência. Flags e padrões do Geth documentam o Geth, não o consenso Ethereum nem todos os provedores.
  4. Observe a propagação sem inventar uma visão global. Compare hash e bytes assinados da transação bruta entre nós independentes, mas trate a ausência como ambígua: o nó pode não tê-la recebido, rejeitá-la pela política local, tê-la removido ou não expor o pool. Uma rota privada pode evitar o gossip público e ainda compartilhar a transação com operadores e builders.
  5. Modele elegibilidade e ordenação no bloco candidato. Para uma transação tipo 2, o preço do gas de execução é min(maxFeePerGas, baseFeePerGas + maxPriorityFeePerGas); se a taxa base superar a taxa máxima, a transação não é elegível sob esse teto. Dependências de nonce, limites de gas e blob, validade do estado, bundles de builders e MEV podem importar mais que a ordem de chegada.
  6. Gerencie deliberadamente o ciclo de vida. Aguarde ou envie uma substituição documentada com o mesmo nonce somente após confirmar cadeia ativa, remetente e política de substituição. Uma transferência para si com o mesmo nonce é apenas outra candidata a substituição, não uma primitiva de cancelamento. Nunca repita uma transferência de valor porque um explorador deixou de mostrar a original.
  7. Reconcilie com o estado de consenso. Preserve cada hash assinado e a linhagem de substituições; depois confira recibo canônico, hash do bloco, status, gas usado, logs, nonce consumido e estado da conta ou contrato no nível exigido de confirmação ou finalidade. Se uma reorganização remover o bloco, uma transação ainda válida pode voltar a alguns pools locais, mas isso depende do cliente e do estado.

Exemplos detalhados

  • Elegibilidade pelo teto da taxa. Uma transferência tipo 2 tem gasUsed = 21,000, baseFeePerGas = 32 gwei, maxPriorityFeePerGas = 3 gwei e maxFeePerGas = 34 gwei. Seu preço efetivo é min(34, 32 + 3) = 34 gwei, portanto a gorjeta real é 2 gwei. A taxa é 21,000 * 34 = 714,000 gwei = 0.000714 ETH, dividida em 0.000672 ETH de taxa base queimada e 0.000042 ETH de gorjeta. Se a taxa base do bloco candidato subir para 35 gwei, o teto de 34 gwei não basta para esse bloco.
  • Lacuna de nonce. O nonce canônico da conta é 10. Um pool local recebe transações com nonces 10 e 12, mas nenhuma com 11; pode classificar 10 como pendente e 12 como em fila. Após incluir o nonce 10, o nonce canônico passa a 11, e 12 continua bloqueado até a inclusão de uma transação válida de nonce 11. Ver o nonce 12 em um pool não o torna executável de forma independente.
  • Substituição específica da política. Em uma configuração didática do Geth com txpool.pricebump = 10, uma transação antiga tem maxFeePerGas = 40 gwei e maxPriorityFeePerGas = 2 gwei. Um incremento de 10% produz limites de 44 gwei e 2.2 gwei. Uma proposta de 43 gwei e 3 gwei ainda pode ser rejeitada porque um teto não alcança o incremento configurado; 44 gwei e 2.2 gwei alcançam ambos os limites didáticos. Arredondamento inteiro, tipo de transação e lógica exata de aceitação dependem da versão, e outro nó pode manter outra candidata.
  • Não há pool global. O nó A informa 120,000 hashes distintos, o nó B informa 100,000, e a interseção é 80,000. A união é 120,000 + 100,000 - 80,000 = 140,000; a sobreposição de Jaccard é 80,000 / 140,000 = 57.1428571429%. Há 40,000 hashes visíveis apenas para A e 20,000 apenas para B. Nenhuma contagem prova o que um builder, relay privado ou o restante da rede consegue ver.

Riscos

  • Assinar ou transmitir na chain ID ou rede errada.
  • Confiar em endpoint RPC malicioso, desatualizado ou mal configurado.
  • Assinatura, tipo, codificação ou sidecar de blob inválidos.
  • Saldo insuficiente para valor mais exposição máxima a taxas.
  • Rejeição prévia por regras de gas intrínseco ou calldata.
  • Nonce já consumido ou baixo demais.
  • Lacuna de nonce que deixa transações posteriores em fila.
  • Substituição de mesmo nonce rejeitada como barata pela política local.
  • Taxa máxima inferior à taxa base do bloco candidato.
  • Baixa prioridade efetiva ou restrições de recursos atrasando inclusão.
  • Divergência de política entre cliente, provedor, versão ou configuração.
  • Capacidade, expiração, reinício ou remoção do pool eliminando a transação.
  • Propagação ruim, eclipse ou retransmissão seletiva.
  • Vazamento, censura, indisponibilidade ou falta de builders no relay privado.
  • Frontrunning, sandwich ou outro MEV sobre fluxo público.
  • Reordenação por builders, bundles ou transações privadas alterando o estado.
  • Simulação ficando obsoleta antes da inclusão.
  • Envio duplicado às cegas ou perda da linhagem de substituição.
  • REVERT incluído, falta de gas ou falha capturada em subchamada apesar da admissão.
  • Reorganização, confusão de finalidade ou tratar mempool ERC-4337 como txpool comum.

Equívocos comuns

  • O mempool é uma fila FIFO única, global e sincronizada.
  • Um hash prova que a rede aceitou ou propagou a transação.
  • Pendente significa incluída, bem-sucedida, irreversível ou paga ao destinatário.
  • Uma taxa suficientemente alta garante inclusão e execução bem-sucedida.
  • Uma rota privada é automaticamente confidencial, resistente à censura e garantida.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...