Ir para o conteúdo
Financial Context Wiki

RPC para transações privadas

Um RPC para transações privadas encaminha uma transação assinada ou bundle a um conjunto limitado de provedores, relays ou builders antes da propagação no mempool público; ele altera a divulgação inicial, não as garantias de validade, inclusão, preço ou finalidade.

Atualizado

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

Resposta direta

Um RPC para transações privadas envia uma transação assinada ou bundle ordenado por um caminho de serviço limitado antes da propagação no mempool público. O caminho pode incluir um provedor RPC, relay, builders selecionados e, quando há hints divulgados, searchers. Portanto, “privado” descreve a distribuição inicial, não criptografia, anonimato nem invisibilidade para intermediários.

O serviço pode reduzir a exposição a cópias, front-running ou ataques sandwich no mempool público, mas não garante inclusão, sucesso na EVM, melhor execução, reembolso de MEV nem finalidade. A confirmação do provedor ou o hash de transação retornado comprova apenas que a solicitação chegou àquela interface. Distribuição para builders, seleção do payload, inclusão em bloco, status do recibo, canonicalidade e finalidade são estados distintos.

Não trate todos os métodos privados como equivalentes. Uma chamada individual a eth_sendPrivateTransaction, um eth_sendBundle legado e um mev_sendBundle podem diferir em blocos-alvo, corpos ordenados, reverts permitidos, substituição ou cancelamento, seleção de builders, hints de privacidade e regras de reembolso. A cadeia, o endpoint, a versão da API e o payload assinado exatos controlam o resultado.

Como funciona

A wallet primeiro constrói e assina uma transação comum da cadeia com chain ID, nonce, destino, valor, calldata, limite de gas e limites de taxa EIP-1559. O encaminhamento privado muda onde esses bytes assinados são enviados; não contorna a ordem dos nonces, verificações de saldo e allowance, execução do contrato, regras de base fee nem validação por consenso. Retransmitir bytes assinados idênticos preserva o hash da transação, enquanto uma substituição com o mesmo nonce e taxas ou calldata diferentes produz outro hash.

O provedor pode simular o payload contra um estado identificado e distribuí-lo a um ou mais builders. A simulação depende desse estado: saldos, storage, valores de oráculos, transações concorrentes e base fee podem mudar antes da construção. Um builder pode omitir uma transação válida porque ela chegou tarde, pagou pouco, perdeu para um bloco mais valioso ou nunca alcançou o builder selecionado pelo proposer.

Bundles acrescentam uma política de execução ordenada. Um revert obrigatório pode tornar um bundle inelegível, enquanto um revert explicitamente permitido pode consumir gas e deixar vigentes mudanças de estado anteriores do bundle. Isso não é uma reversão atômica automática de tudo. Hints de privacidade podem divulgar hash, endereço do contrato, seletor de função, calldata ou logs; um modo rápido ou com muitos builders amplia o alcance e, em geral, o conjunto de confiança e divulgação.

O gerenciamento de nonce e timeout exige uma máquina de estados explícita. Uma transação privada pendente pode não aparecer na visão pending de um RPC público comum e pode bloquear nonces posteriores. O cancelamento pelo provedor só interrompe envios futuros pelos caminhos que ele controla; não recupera uma cópia já compartilhada, transmitida publicamente ou incluída. Uma substituição com o mesmo nonce ou fallback público disputa com todas as versões sobreviventes e reintroduz a exposição pública do fluxo de ordens.

Use este fluxo de trabalho:

  1. Fixe o chain ID, o provedor e a versão da API; escolha um método de transação privada individual ou bundle e documente as políticas de logs do provedor, distribuição a builders ou searchers, hints de privacidade, revert, reembolso e fallback público.
  2. Decodifique a intenção não assinada e o payload assinado exatos: remetente, nonce, destino, valor, calldata, allowances, limite de gas, limites de taxa, deadline, output mínimo, intervalo de blocos-alvo e cada item ordenado do bundle.
  3. Simule contra bloco e estado identificados; teste sucesso e revert, mudança de estado, slippage, variações de saldo, falhas permitidas, gas total e o pior resultado economicamente válido.
  4. Envie pelo endpoint pretendido e preserve o hash da transação ou bundle, ID da solicitação, identidade de autenticação, timestamp, bloco-alvo ou máximo, builders, hints e payload original.
  5. Monitore separadamente a confirmação do provedor, simulação, distribuição a builders, nonce privado e expiração em relação ao recibo canônico; atualize as premissas de alvo e taxa antes de reenviar.
  6. No deadline, escolha explicitamente entre esperar, cancelar, substituir com o mesmo nonce ou divulgar por fallback público; nunca presuma que o cancelamento recupera cópias nem envie versões conflitantes sem acompanhar a disputa.
  7. Reconcilie na cadeia correta o status do recibo, logs, saldos, output, preço efetivo do gas e reembolso; depois aguarde o estado safe ou finalized exigido e investigue reorgs, vazamentos ou diferenças de execução sem explicação.

Exemplos

  • Proteção de output não é melhor execução. Um swap indica entrada de 100,000 USDC com output mínimo de 98,800 USDC. A execução pública devolve 98,950 USDC, uma diferença de 1,050 USDC ou 1.05% em relação ao par, mas apenas 150 USDC acima do mínimo. O encaminhamento privado pode reduzir a observação; ele não garante output melhor que outro mercado público ou RFQ.
  • Limite de inclusão EIP-1559. Uma transação usa 180,000 gas, a base fee é 30 gwei, o limite de prioridade é 2 gwei e a taxa máxima é 40 gwei. O preço efetivo é min(40, 30 + 2) = 32 gwei, portanto a taxa é 180,000 x 32 = 5,760,000 gwei = 0.005760 ETH. Se a base fee de um bloco candidato for 42 gwei, a taxa máxima de 40 gwei não a cobre, e o encaminhamento privado não torna a transação elegível para inclusão ali.
  • Disputa do fallback com o mesmo nonce. O payload privado A e o fallback público B usam nonce 42. Há dois envios, mas a cadeia canônica só pode consumir o nonce 42 uma vez. Se A entrar no bloco N + 2, B fica obsoleto; se B entrar primeiro, A fica obsoleto. Uma confirmação de cancelamento não desfaz a operação, e toda cópia sobrevivente deve ser acompanhada.
  • Revert permitido não é reversão atômica. Em um bundle ordenado, a aprovação usa 45,000 gas e um swap reverte após 120,000 gas a um preço efetivo de 25 gwei. Sem regra de revert permitido, o bundle é excluído sob a política declarada. Se o swap puder reverter e o bundle for incluído, a aprovação pode persistir, o swap terá status = 0 e o custo de gas será (45,000 + 120,000) x 25 gwei = 0.004125 ETH.

Riscos

  • A wallet usa cadeia, provedor, endpoint ou versão de API incorretos.
  • DNS, TLS, API key ou interface RPC sofre phishing ou comprometimento.
  • O provedor correlaciona IP, conta, horário e dados do payload assinado.
  • Um relay registra, vaza, copia ou retransmite publicamente a transação completa.
  • Hints de privacidade divulgam hash, seletor, contrato, calldata ou logs.
  • O modo rápido ou ampla distribuição a builders aumenta o conjunto de confiança e divulgação.
  • Um builder ou searcher censura, copia ou explora o fluxo de ordens privado.
  • A simulação usa o bloco errado ou fica obsoleta antes da construção.
  • Estado do contrato, saldos, preços ou ordenação mudam e causam revert.
  • Base fee, taxa máxima ou prioridade tornam o payload pouco atraente ou inválido.
  • Uma lacuna de nonce ou transação privada pendente invisível bloqueia nonces posteriores.
  • O cancelamento ou substituição com o mesmo nonce perde uma disputa temporal.
  • Um fallback público silencioso restaura a exposição a MEV do mempool público.
  • Bloco-alvo, bloco máximo, timestamp ou TTL do serviço é mal interpretado.
  • A ordem do bundle ou a política de reverts permitidos deixa uma mudança de estado indesejada.
  • Cobertura ou censura de builders, relays ou proposers impede a inclusão.
  • Indisponibilidade, rate limiting ou latência do provedor perde a janela válida.
  • Encaminhamento privado é confundido com proteção contra slippage ou melhor execução.
  • Status do recibo, logs, saldos, taxas ou reembolsos são reconciliados incorretamente.
  • Um reorg, premissa prematura de finalidade ou limite de sequenciador L2 reverte a conclusão.

Equívocos comuns

  • Privado significa criptografado, anônimo e invisível. O provedor e as partes downstream selecionadas podem ver o payload completo ou os hints divulgados.
  • Um RPC privado garante ausência de MEV e o melhor preço. Ele muda a distribuição; limites contratuais, comparação de mercados e qualidade da execução continuam relevantes.
  • Sucesso do RPC ou hash da transação significa inclusão, sucesso e finalidade. Confirmação, recibo, estado da EVM e finalidade são estados diferentes.
  • Cancelamento ou substituição com o mesmo nonce é garantido. Cópias e versões concorrentes disputam até que uma seja incluída ou todas expirem.
  • Uma transação privada é automaticamente um bundle atômico. Transações individuais e diferentes formatos de bundle têm semânticas distintas de ordem e revert.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...