--- title: "Protection contre le replay des messages inter-chaînes" description: "La protection contre le replay lie un message source authentifié a une version du protocole et a un domaine de destination, tout en autorisant les nouvelles tentatives sans produire plus d'un effet économique réussi." 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. # Protection contre le replay des messages inter-chaînes > À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes. ## Reponse directe La protection contre le replay des messages inter-chaînes garantit qu'un message source authentifié ne produit pas plus d'un effet économique réussi dans le domaine de destination prévu. Un relayer peut livrer plusieurs fois la meme preuve et une tentative échouée peut etre relancée, mais un message terminé ne doit plus émettre, déverrouiller ni rappeler le destinataire. Authenticité, finalité et protection contre le replay sont des controles distincts. Une signature, une attestation de validateurs ou une preuve de stockage valide peut authentifier des données sans prouver que l'événement source est final, que la destination et le destinataire sont lies ou que la destination ne l'a pas déjà traite. Un relayer autorisé n'est qu'une voie de livraison ; son identite ne remplace pas l'authentification du message. Il n'existe pas de `messageId` inter-chaînes universel. La spécification du protocole définit la sérialisation et l'identite. Une enveloppe robuste lie généralement protocole et version, domaine et messenger ou emitter source, expéditeur source, nonce ou identite de transaction/log source, domaine et destinataire cible, valeur, payload et éventuelle expiration. Wormhole, CCTP, Optimism et ERC-5164 utilisent des champs et machines a états différents ; leurs identifiants ne sont pas interchangeables. ## Fonctionnement Une action source émet ou stocke un message. Après la politique requise de confirmation ou finalité, des validateurs, guardians ou un systeme de preuve l'authentifient. A destination, le vérificateur contrôle la root ou l'ensemble de signatures pertinent, la version, le remote de confiance, la destination, le destinataire, le payload et les limites temporelles. Le destinataire dérive l'identite definie par le protocole et consulté l'état processed persistant avant de produire un effet externe. La livraison est souvent at-least-once, tandis que l'effet metier recherche se produit effectivement une fois. Une machine a états utile distingue jamais tenté, en cours, échoué ou relancable, et réussi ou consomme. L'echec d'un appel cible n'est pas automatiquement une attaque par replay. ERC-5164 exige par exemple au plus une exécution réussie tout en autorisant une nouvelle tentative après echec. Les regles propres au produit sur retry, gas et valeur continuent de s'appliquer. Le flag de replay ou processing guard doit etre établi avant tout appel externe non fiable, avec contrôle de la reentrancy. Si toute la transaction revert, cette modification d'état revert normalement aussi et laisse un chemin de retry défini ; si le protocole intercepte volontairement un echec downstream, il doit enregistrer un état failed distinct sans conserver par erreur de valeur ou d'effets partiels. Le destinataire doit aussi etre idempotent si les systemes downstream sont accessibles par une autre voie. La portee du nonce compte. Un nonce séquentiel impose l'ordre, mais un message manquant peut bloquer les suivants. Un nonce non ordonne ou bitmap autorisé des livraisons independantes, mais exige un calcul exact de word et bit. Un batch doit préciser si l'ensemble est atomique ou si chaque leaf possède sa preuve et son état processed. Ne consommer que la batch root après exécution partielle peut dupliquer les leaf réussies ou bloquer celles qui ont échoué. La politique de réorganisation de la source participe a la sécurité. Une observation signée avant une finalité suffisante peut rester valide cryptographiquement alors que l'événement source n'est plus canonique. Les upgrades constituent une autre frontière : layout du storage du proxy, mappings processed, domaines de version, anciens entry points, rotation des peers et fork ou réutilisation du chain ID doivent conserver ou invalider délibérément les anciennes identites sans rouvrir les messages consommes. Suivre ce processus : 1. Fixer protocole, version déployée, domaines, messenger ou emitter fiable, expéditeur, destinataire, valeur, payload, nonce ou identite d'événement et sémantique d'expiration. 2. Reproduire l'encodage canonique et le vecteur de test de `messageId` ; rejeter concatenation ambiguë, champs omis et hypotheses empruntees a un autre bridge. 3. Vérifier l'inclusion source et la politique requise de finalité ou confirmations, puis la root, le quorum, l'ensemble de validateurs ou guardians et la version corrects. 4. Vérifier séparément destination, destinataire, expéditeur cross-domain, valeur, payload et expiration ; traiter le relayer comme transport, non comme autorite. 5. Lire l'état persistant et passer en processing ou consumed avant tout appel externe non fiable, en testant explicitement reentrancy et revert de la transaction entiere. 6. Définir les transitions successful, failed et retryable, le nonce ordonne ou bitmap, l'atomicite du batch et la comptabilite de valeur ; prouver qu'une livraison répétée ne répète aucune leaf réussie. 7. Tester upgrades, migration du storage, anciens entry points désactivés, rotation des peers, forks et reprise d'urgence ; rapprocher receipts, événements, état processed et soldes cibles. ## Exemples - **Liaison au domaine de destination.** Deux instructions portent le nonce `42` et la valeur `1,000`, mais l'une cible la chain `10` et l'autre la chain `8453`. Un identifiant sans destination traite `2 messages` comme candidats a une collision ; l'encodage canonique qui la lie produit `2 distinct IDs`. La fonction de hachage et la représentation du domaine relevent du protocole. - **Bitmap non ordonne.** Pour le nonce `513`, `word = floor(513 / 256) = 2`, `bit = 513 mod 256 = 1` et `mask = 1 << 1 = 2`. Le premier succes fait passer la word `2` de `0` a `2`. Un doublon trouve `2 & 2 = 2` et est rejeté ; le nonce `512` utilise indépendamment le bit `0`. - **Un retry n'est pas un second effet.** Le meme message est livre `3` fois. Les appels avec `110,000` et `125,000` gas échouent et revert ; le troisieme utilise `140,000` gas et réussit une fois. Le total est `110,000 + 125,000 + 140,000 = 375,000` gas ; a `20 gwei`, il vaut `0.0075 ETH`. Il y a `3` livraisons, mais `1` effet metier réussi. - **Comptabilité d'un batch partiel.** Quatre leaf exécutables séparément portent `25 + 40 + 15 + 20 = 100` unites. Les leaf `0`, `1` et `3` exécutent `25 + 40 + 20 = 85` ; la leaf `2` échoué et laisse `15` en attente. Ne consommer que la root bloque les `15` ; relancer tout le batch sans état par leaf peut repeter les `85`. Il faut un rollback atomique ou un état processed par leaf. ## Risques - L'identifiant omet la chain ou le domaine de destination. - L'identifiant omet le messenger ou l'emitter source. - La version du protocole ou du message manque dans le domaine. - Un namespace de nonce entre en collision entre expediteurs ou deployments. - Un encodage packed ambigu crée des collisions entre champs différents. - Un fork ou chain ID reutilise rend un ancien domaine de nouveau valide. - Un événement est accepte avant une finalité suffisante puis réorganisé. - Une mauvaise root ou un mauvais ensemble de validateurs ou guardians est accepte. - Un ancien domaine de signature reste valide après un upgrade. - Une corruption du storage du proxy réinitialise ou superpose l'état processed. - La migration omet des messages consommes ou laisse un entry point legacy actif. - L'état n'est marque qu'après l'appel externe, ce qui permet la reentrancy. - Un appel échoué est marque réussi et ne peut plus etre relance. - Un appel réussi n'est pas persiste et répète son effet économique. - Un nonce ordonne manquant bloque tous les messages suivants. - L'arithmetique de word, bit ou invalidation du bitmap est erronée. - L'état de la batch root contredit l'exécution partielle des leaf. - Un retry répète des leaf déjà réussies. - Les unites de deadline, expiry ou horloge cible sont mal interprétées. - L'allowlist des relayers est confondue avec l'autorisation du message. ## Idées reçues - **Un nonce seul est globalement unique.** Expediteur, protocole, deployment et domaines définissent son namespace. - **Seul un relayer autorisé empêche le replay.** Le relayer livre ; verification cible et état consumed persistant imposent autorite et contrôle. - **Toute livraison répétée est une attaque.** Un reseau at-least-once peut relancer un echec ; l'invariant est au plus un effet réussi. - **Une preuve ou signature valide démontre finalité et intention.** Elle peut omettre le target, lier la mauvaise version ou attester un état ensuite réorganisé. - **Une transaction bridge réussie prouve exactly-once.** Vérifier receipt, storage processed, événements du destinataire et soldes réels, pour chaque leaf. ## Sujets connexes - [Bridge inter-chaînes](/fr/crypto/cross-chain-bridge/) - [Bridge canonique](/fr/crypto/canonical-bridge/) - [Défaillance d'un relayer inter-chaînes](/fr/crypto/bridge-relayer-liveness-risk/) ## Sources - [ERC-5164: Cross-Chain Execution](https://eips.ethereum.org/EIPS/eip-5164) - Ethereum Improvement Proposals (consulté le 2026-08-13) - [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Improvement Proposals (consulté le 2026-08-13) - [CCTP Technical Guide](https://developers.circle.com/cctp/references/technical-guide) - Circle Developers (consulté le 2026-08-13) - [Interop message passing overview](https://docs.optimism.io/app-developers/guides/interoperability/message-passing) - Optimism Documentation (consulté le 2026-08-13) - [VAAs](https://docs.wormhole.com/protocol/infrastructure/vaas/) - Wormhole Docs (consulté le 2026-08-13) - [Security Considerations](https://docs.soliditylang.org/en/latest/security-considerations.html) - Solidity Documentation (consulté le 2026-08-13) - [Proof-of-stake (PoS)](https://ethereum.org/developers/docs/consensus-mechanisms/pos/) - ethereum.org (consulté le 2026-08-13) - [Upgrading smart contracts](https://docs.openzeppelin.com/contracts/5.x/learn/upgrading-smart-contracts) - OpenZeppelin Docs (consulté le 2026-08-13) Source: https://wiki.fcontext.com/fr/crypto/bridge-message-replay-protection/index.mdx