Ir para o conteúdo
Financial Context Wiki

Risco de disponibilidade de relayer cross-chain

Risco de uma mensagem autenticada não ser entregue ou executada a tempo; o diagnóstico separa finalidade, prova, entrega, execução e contabilidade.

Atualizado

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

Resposta direta

O risco de disponibilidade de relayer cross-chain é o risco de uma mensagem válida e autenticada não ser enviada ou executada a tempo no destino. O relayer normalmente transporta mensagem e prova ou metadata; ele não torna o evento de origem final nem autoriza o payload. Consenso da origem, produção de prova ou atestado, verificação no destino e execução pelo receiver são dependências distintas.

O atraso é inicialmente um problema de disponibilidade, não prova de roubo. Ainda assim, pode gerar custo financeiro, perda de prazo, tickets expirados, liquidez indisponível ou perda permanente conforme o produto. Um receipt na origem e o rótulo Pending também não provam falha do relayer: a origem pode não ser final, a prova pode faltar, o destino pode estar pausado, o gas subfinanciado ou o receiver reverter.

A entrega permissionless depende do protocolo. Hyperlane e Wormhole descrevem rotas em que terceiros entregam mensagens autenticadas; outros deployments restringem executors, destination callers ou recuperação. Envio aberto não permite alterar payload autenticado, e allowlist de relayer não substitui verificação ou replay protection.

Como funciona

Um ciclo analítico separa source submitted, source finalized, proof pending, ready, destination submitted, failed/retryable, executed e expired/cancelled. São rótulos analíticos; cada protocolo tem campos próprios. Withdrawal do OP Stack, mensagem burn-and-mint do CCTP, VAA do Wormhole e mensagem Hyperlane têm regras diferentes de prova, prazo, fee e retry.

Primeiro confirme se a ação na origem bloqueou, queimou ou despachou valor e atingiu a finalidade exigida. Depois, confirme disponibilidade e vigência de root, assinaturas de validadores, VAA de guardians ou attestation. Só então verifique se o relayer observou a mensagem, aceitou sua política de fees, montou metadata correta e a enviou ao contrato exato.

A execução no destino falha de modo independente: indisponibilidade de chain ou sequencer, RPC obsoleto, pausa, versão errada do receiver, gas insuficiente, bloqueio por nonce ordenado, expiry ou revert da aplicação. Hash de transação é apenas referência de envio. A conclusão exige receipt bem-sucedido, estado processed, evento ou mudança do receiver, token correto e efeito esperado no saldo sob a finalidade necessária.

Relay manual não é resgate universal. Só é possível quando o protocolo implantado expõe entry point elegível, mensagem e prova originais estão disponíveis, o caller é permitido, a mensagem não foi consumida nem expirou e o caller financia gas e valor no destino. Simule a chamada oficial. Nunca crie novo lock ou burn na origem para corrigir uma primeira mensagem não diagnosticada.

Retry e replay são diferentes. Retry documentado reapresenta a mesma mensagem canônica após falha do efeito de destino; estado consumed ou nonce correto permite no máximo um efeito bem-sucedido. Relayers podem competir e gastar gas sem comprometer a segurança. Cancelar tarefa local não recolhe transação já transmitida ou incluída.

Use este fluxo:

  1. Fixe protocolo, lane, versão, domínios e contratos, transação e log de origem, ID ou nonce, ação do ativo, raw amount, receiver e expiry.
  2. Verifique receipt e evento de origem e aplique a regra de confirmação ou finalidade; confira identidade do bloco e reorg, não apenas a interface.
  3. Localize proof, VAA, attestation, checkpoint ou root; confira estado de origem, versão, signer set, disponibilidade e invalidação ou expiry.
  4. Verifique saúde do destino, versões de messenger/receiver, pausa, nonce ou processed state, predecessores, deadline e gas nativo.
  5. Determine se a entrega é permissionless, allowlisted ou restrita; na rota manual elegível, reconstrua e simule payload, prova e chamada oficiais originais.
  6. Atualize gas limit, price, margem cambial, fee cap, refund e expiry; envie ou repita a mesma mensagem, trate corridas de duplicação/replacement e guarde o receipt.
  7. Reconcilie escrow ou burn, passivo in-flight, mint, unlock ou call, fees, refunds e estado final; escale por canais documentados sem fornecer seed phrase ou private key.

Exemplos

  • Atribuição do atraso. Finalidade leva 12 minutes, prova 8 minutes, fila do relayer 35 minutes e inclusão 5 minutes. Total: 12 + 8 + 35 + 5 = 60 minutes. Só a fila de 35-minute pertence à delivery liveness; os primeiros 20 minutes e últimos 5 minutes têm outros responsáveis.
  • Cotação de gas insuficiente. Limite 300,000. A 25 gwei, custo 300,000 * 25 * 10^-9 = 0.0075 ETH. Na execução, 60 gwei exige 0.018 ETH, faltando 0.018 - 0.0075 = 0.0105 ETH. Mais gas na origem não necessariamente financia o destino.
  • Relayers duplicados gastam gas, não principal. Três enviam a mensagem de 100,000 USDC. O vencedor usa 180,000 gas * 30 gwei = 0.0054 ETH; dois revertem após 70,000 gas * 30 gwei = 0.0021 ETH cada. Total 0.0054 + 0.0021 + 0.0021 = 0.0096 ETH; replay state correto permite 100,000 USDC, não 300,000 USDC.
  • Passivo em trânsito. Rota lock-and-mint bloqueia 25 ETH; após falha, escrow +25 ETH, wrapped supply +0 ETH, passivo in-flight 25 ETH. Retry correto mantém escrow 25 ETH, eleva supply a 25 ETH e reduz passivo a 0 ETH. Novo depósito de 25 ETH criaria 50 ETH em escrow e duas obrigações.

Riscos

  • Transação de origem fica pending ou reverte enquanto a interface diz enviada.
  • Evento é usado antes da finalidade suficiente.
  • Reorg remove ou altera o evento.
  • Proof, attestation, checkpoint ou assinaturas não estão disponíveis.
  • Root ou signer set obsoleto, errado ou invalidado é usado.
  • Chave ou serviço de relayer allowlisted fica indisponível.
  • Permissionless é confundido com entrega pontual garantida.
  • Entry point restrito é confundido com rota manual pública.
  • Chain, sequencer, RPC ou indexer de destino está indisponível ou obsoleto.
  • Messenger ou receiver de destino está pausado.
  • Upgrade ou address mismatch do receiver causa revert.
  • Gas limit de destino é baixo.
  • Gas quote, câmbio, fee cap ou refund fica obsoleto.
  • Wallet não tem o ativo de gas nativo correto.
  • Mensagem, ticket, proof ou deadline expira.
  • Lacuna de nonce ordenado bloqueia mensagens posteriores.
  • Lógica retry/consumed duplica ou impede recuperação.
  • Corridas de duplicação, cancelamento ou replacement gastam gas.
  • Suporte falso fornece contratos, provas ou calldata maliciosos.
  • Lock/burn, claims in-flight, efeitos, fees e refunds são mal reconciliados.

Erros comuns

  • O relayer autentica a mensagem. A entrega leva evidência; verifier e aplicação de destino aplicam origem, sender, payload e replay.
  • Falha do relayer significa perda ou refund automático. Primeiro há atraso; expiry, recuperação, solvência e refund dependem do produto.
  • Permissionless permite mudar payload ou garante execução imediata. Autenticação impede mudança; proof, gas, chain e receiver controlam liveness.
  • Todo retry duplica o mint. O retry correto reutiliza uma mensagem e permite um efeito; nova transferência cria nova obrigação.
  • Hash de destino ou rótulo completed prova recebimento. Confirme receipt, processed state, eventos, saldos, token e finalidade.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...