--- title: "Proteção contra replay de mensagens cross-chain" description: "A proteção contra replay vincula uma mensagem de origem autenticada a uma versão do protocolo e a um domínio de destino, permitindo novas tentativas sem mais de um efeito econômico bem-sucedido." image: "https://wiki.fcontext.com/og.png" --- > Documentation Index > Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt > Use this file to discover all available pages before exploring further. # Proteção contra replay de mensagens cross-chain > Somente para fins educacionais; não constitui recomendação nem aconselhamento de investimento. Investir pode causar perdas. ## Resposta direta A proteção contra replay de mensagens cross-chain garante que uma mensagem de origem autenticada produza no maximo um efeito econômico bem-sucedido no domínio de destino pretendido. Um relayer pode entregar a mesma prova repetidamente, e uma tentativa que falhou pode ser repetida, mas uma mensagem concluida não pode emitir, desbloquear nem chamar o destinatario novamente. Autenticidade, finalidade e proteção contra replay são verificacoes separadas. Uma assinatura, atestação de validadores ou prova de armazenamento válida pode autenticar dados sem provar que o evento de origem e final, que destino e destinatario foram vinculados ou que o destino ainda não o processou. Um relayer autorizado e apenas a rota de entrega; sua identidade não substitui a autenticação da mensagem. Nao existe `messageId` cross-chain universal. A especificação do protocolo define serialização e identidade. Um envelope robusto costuma vincular protocolo e versão, domínio e messenger ou emissor de origem, remetente, nonce ou identidade da transação/log, domínio e destinatario de destino, valor, payload e eventual expiração. Wormhole, CCTP, Optimism e ERC-5164 usam campos e maquinas de estado diferentes; seus identificadores não são intercambiaveis. ## Como funciona Uma ação na origem emite ou armazena a mensagem. Depois da política exigida de confirmação ou finalidade, validadores, guardians ou um sistema de provas a autenticam. No destino, o verificador confere raiz ou conjunto de assinaturas, versão, remoto confiavel, destino, destinatario, payload e limites temporais. O destinatario deriva a identidade definida pelo protocolo e consulta o estado processed persistente antes de gerar um efeito externo. A entrega costuma ser at-least-once, enquanto o efeito de negocio pretendido ocorre efetivamente uma vez. Uma máquina de estados útil distingue nunca tentada, em processamento, falha ou repetivel, e bem-sucedida ou consumida. Uma chamada de destino que falha não e automaticamente um ataque de replay. O ERC-5164, por exemplo, exige no maximo uma execucao bem-sucedida, permitindo nova tentativa após falha. Regras especificas de retry, gas e valor continuam valendo. O flag de replay ou guard de processamento deve ser definido antes de uma chamada externa não confiavel, com controle de reentrancia. Se toda a transação reverter, esse estado normalmente também reverte e preserva uma rota definida de retry; se o protocolo capturar intencionalmente uma falha downstream, deve registrar um estado de falha distinto sem reter valor nem efeitos parciais por engano. O destinatario também deve ser idempotente quando sistemas downstream puderem ser chamados por outra rota. O escopo do nonce importa. Um nonce sequencial impõe ordem, mas uma mensagem ausente pode bloquear as seguintes. Um nonce não ordenado ou bitmap permite entrega independente, mas exige cálculo exato de word e bit. Em lotes, deve-se definir se tudo e atômico ou se cada folha tem prova e estado processed independentes. Consumir apenas a raiz depois de execucao parcial pode duplicar folhas bem-sucedidas ou impedir as que falharam. A política de reorganização da origem integra a seguranca contra replay. Uma observação assinada antes de finalidade suficiente pode continuar criptograficamente válida mesmo se o evento deixar de ser canonico. Upgrades são outro limite: layout de storage do proxy, mappings processed, domínios de versão, entry points antigos, rotação de peers e fork ou reutilizacao de chain ID devem preservar ou invalidar deliberadamente identidades antigas sem reabrir mensagens consumidas. Use este fluxo: 1. Fixe protocolo, versão implantada, domínios, messenger ou emissor confiavel, remetente, destinatario, valor, payload, nonce ou identidade do evento e semântica de expiração. 2. Reproduza a codificação canonica e o vetor de teste de `messageId`; rejeite concatenacao ambigua, campos omitidos e suposicoes emprestadas de outra bridge. 3. Verifique inclusão e política de finalidade ou confirmação e, depois, raiz, quorum, conjunto de validadores ou guardians e versão corretos. 4. Verifique separadamente destino, destinatario, remetente cross-domain, valor, payload e expiração; trate o relayer como transporte, não como autoridade. 5. Leia o estado persistente e entre em processing ou consumed antes de chamada externa não confiavel, testando reentrancia e comportamento de revert. 6. Defina transicoes de sucesso, falha e retry, nonce ordenado ou bitmap, atomicidade do lote e contabilidade de valor; prove que nova entrega não repete uma folha bem-sucedida. 7. Teste upgrades, migração de storage, entry points legacy desativados, rotação de peers, forks e recuperação; reconcilie receipts, eventos, estado processed e saldos no destino. ## Exemplos - **Vinculo ao domínio de destino.** Duas instrucoes trazem nonce `42` e valor `1,000`, mas uma aponta para a chain `10` e outra para a chain `8453`. Um identificador que omite o destino trata `2 messages` como candidatas a colisão; a codificação canonica que o vincula gera `2 distinct IDs`. Hash e representação do domínio são definidos pelo protocolo. - **Bitmap não ordenado.** Para nonce `513`, `word = floor(513 / 256) = 2`, `bit = 513 mod 256 = 1` e `mask = 1 << 1 = 2`. O primeiro sucesso altera a word `2` de `0` para `2`. Uma duplicata encontra `2 & 2 = 2` e e rejeitada; nonce `512` usa o bit `0` de forma independente. - **Retry não cria outro efeito.** A mesma mensagem e entregue `3` vezes. Chamadas com `110,000` e `125,000` gas falham e revertem; a terceira usa `140,000` gas e tem um sucesso. O gas total e `110,000 + 125,000 + 140,000 = 375,000`; a `20 gwei`, equivale a `0.0075 ETH`. Sao `3` entregas, mas `1` efeito de negocio bem-sucedido. - **Contabilidade de lote parcial.** Quatro folhas executaveis separadamente carregam `25 + 40 + 15 + 20 = 100` unidades. As folhas `0`, `1` e `3` executam `25 + 40 + 20 = 85`; a folha `2` falha e deixa `15` pendentes. Consumir apenas a raiz prende as `15`; repetir tudo sem estado por folha pode repetir as `85`. Use rollback atômico ou estado processed por folha. ## Riscos - O identificador omite a chain ou domínio de destino. - O identificador omite o messenger ou emissor de origem. - A versão do protocolo ou da mensagem está ausente do domínio. - Um namespace de nonce colide entre remetentes ou deployments. - Codificacao packed ambigua cria colisoes entre campos diferentes. - Um fork ou chain ID reutilizado torna um domínio antigo valido. - Um evento e aceito antes de finalidade suficiente e sai por reorg. - A raiz ou o conjunto de validadores ou guardians errado e aceito. - Um domínio de assinatura antigo continua valido após upgrade. - Corrupcao do storage do proxy reinicia ou sobrepoe estado processed. - A migração omite consumidos ou mantem entry point legacy ativo. - O estado e marcado so depois da chamada externa, permitindo reentrancia. - Uma chamada falha e marcada como sucesso e nunca pode ter retry. - Uma chamada bem-sucedida não persiste e repete o efeito econômico. - Um nonce ordenado ausente bloqueia todas as mensagens posteriores. - A aritmética de word, bit ou invalidacao do bitmap está errada. - O estado da raiz do lote conflita com execucao parcial por folha. - Um retry repete folhas que já tiveram sucesso. - Unidades de deadline, expiry ou relogio de destino são mal interpretadas. - A allowlist de relayers e confundida com autorização da mensagem. ## Erros comuns - **Um nonce sozinho e globalmente unico.** Remetente, protocolo, deployment e domínios definem seu namespace. - **Somente relayer autorizado impede replay.** Relayers entregam; verificação no destino e estado consumed persistente impoem autorização e controle. - **Toda entrega repetida e ataque.** Redes at-least-once podem repetir uma falha; a invariante e no maximo um efeito bem-sucedido. - **Prova ou assinatura válida demonstra finalidade e intencao.** Pode omitir o target, vincular versão errada ou atestar estado depois reorganizado. - **Transacao bem-sucedida prova conclusao exactly-once.** Confira receipt, storage processed, eventos do destinatario e saldos, inclusive cada folha. ## Tópicos relacionados - [Bridge cross-chain](/pt-br/crypto/cross-chain-bridge/) - [Bridge canonica](/pt-br/crypto/canonical-bridge/) - [Falha de relayer cross-chain](/pt-br/crypto/bridge-relayer-liveness-risk/) ## Fontes - [ERC-5164: Cross-Chain Execution](https://eips.ethereum.org/EIPS/eip-5164) - Ethereum Improvement Proposals (acesso: 2026-08-13) - [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Improvement Proposals (acesso: 2026-08-13) - [CCTP Technical Guide](https://developers.circle.com/cctp/references/technical-guide) - Circle Developers (acesso: 2026-08-13) - [Interop message passing overview](https://docs.optimism.io/app-developers/guides/interoperability/message-passing) - Optimism Documentation (acesso: 2026-08-13) - [VAAs](https://docs.wormhole.com/protocol/infrastructure/vaas/) - Wormhole Docs (acesso: 2026-08-13) - [Security Considerations](https://docs.soliditylang.org/en/latest/security-considerations.html) - Solidity Documentation (acesso: 2026-08-13) - [Proof-of-stake (PoS)](https://ethereum.org/developers/docs/consensus-mechanisms/pos/) - ethereum.org (acesso: 2026-08-13) - [Upgrading smart contracts](https://docs.openzeppelin.com/contracts/5.x/learn/upgrading-smart-contracts) - OpenZeppelin Docs (acesso: 2026-08-13) Source: https://wiki.fcontext.com/pt-br/crypto/bridge-message-replay-protection/index.mdx