--- title: "Protezione dal replay dei messaggi cross-chain" description: "La protezione dal replay vincola un messaggio sorgente autenticato a una versione del protocollo è a un dominio di destinazione, consentendo nuovi tentativi senza più di un effetto economico riuscito." 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. # Protezione dal replay dei messaggi cross-chain > Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite. ## Risposta diretta La protezione dal replay dei messaggi cross-chain assicura che un messaggio sorgente autenticato produca al massimo un effetto economico riuscito nel dominio di destinazione previsto. Un relayer può consegnare più volte la stessa prova è un tentativo fallito può essere ripetibile, ma un messaggio completato non deve coniare, sbloccare o chiamare nuovamente il destinatario. Autenticita, finalità è protezione dal replay sono verifiche separate. Una firma, attestazione dei validatori o storage proof valida può autenticare i dati senza dimostrare che l'evento sorgente sia finalizzato, che destinazione è destinatario siano vincolati o che la destinazione non l'abbia già elaborato. Un relayer autorizzato è solo il canale di consegna; la sua identità non sostituisce l'autenticazione del messaggio. Non esiste un `messageId` cross-chain universale. La specifica del protocollo determina serializzazione è identità. Un envelope robusto vincola di norma protocollo è versione, dominio è messenger o emitter sorgente, mittente originale, nonce o identità di transazione/log sorgente, dominio è destinatario di arrivo, valore, payload ed eventuale scadenza. Wormhole, CCTP, Optimism ed ERC-5164 usano campi è macchine a stati diversi; gli identificatori non sono intercambiabili. ## Come funziona Un'azione sorgente emette o memorizza un messaggio. Dopo la policy richiesta di conferma o finalità, validatori, guardian o un proof system lo autenticano. A destinazione, il verificatore controlla root o insieme di firme, versione, controparte fidata, destinazione, destinatario, payload è limiti temporali. Il destinatario deriva l'identità definita dal protocollo è consulta lo stato processed persistente prima di produrre un effetto esterno. La consegna è spesso at-least-once, mentre l'effetto commerciale desiderato si verifica effettivamente una volta. Una macchina a stati utile distingue mai tentato, in elaborazione, fallito o ripetibile, è riuscito o consumato. Una chiamata di destinazione fallita non è automaticamente un attacco di replay. ERC-5164, per esempio, impone al massimo un'esecuzione riuscita è permette un altro tentativo dopo il fallimento. Restano applicabili le regole specifiche su retry, gas è valore. Il flag di replay o processing guard va impostato prima di una chiamata esterna non fidata, controllando la reentrancy. Se l'intera transazione fa revert, di norma anche quel cambiamento di stato viene annullato è resta un percorso definito di retry; se il protocollo intercetta intenzionalmente un errore downstream, deve registrare uno stato failed distinto senza trattenere per errore valore o effetti parziali. Il destinatario dovrebbe essere idempotente anche quando sistemi downstream sono raggiungibili per un'altra via. Lo scope del nonce conta. Un nonce sequenziale impone l'ordine, ma una voce mancante può bloccare i messaggi successivi. Un nonce non ordinato o bitmap permette consegne indipendenti, ma richiede un calcolo esatto di word è bit. I batch devono stabilire se tutto il lotto è atomico o se ogni leaf ha proof è stato processed propri. Consumare soltanto la root dopo un'esecuzione parziale può duplicare leaf riuscite o bloccare quelle fallite. La policy di riorganizzazione della sorgente fa parte della sicurezza. Un'osservazione firmata prima di sufficiente finalità può restare crittograficamente valida anche se l'evento sorgente non è più canonico. Gli upgrade sono un altro confine: layout dello storage del proxy, mapping processed, domini di versione, vecchi entry point, rotazione dei peer è fork o riuso del chain ID devono preservare o invalidare deliberatamente le identità pregresse senza riaprire messaggi consumati. Usare questo flusso: 1. Fissare protocollo, versione distribuita, domini, messenger o emitter fidato, mittente, destinatario, valore, payload, nonce o identità dell'evento è semantica della scadenza. 2. Riprodurre encoding canonico è test vector di `messageId`; rifiutare concatenazioni ambigue, campi omessi è assunzioni importate da un altro bridge. 3. Verificare inclusione è policy richiesta di finalità o conferme, quindi root, quorum di firme, set di validatori o guardian è versione corretti. 4. Verificare separatamente destinazione, destinatario, mittente cross-domain, valore, payload è scadenza; trattare il relayer come trasporto, non autorita. 5. Leggere lo stato persistente ed entrare in processing o consumed prima di chiamate esterne non fidate, testando esplicitamente reentrancy è revert dell'intera transazione. 6. Definire transizioni successful, failed è retryable, nonce ordinato o bitmap, atomicità del batch è contabilità del valore; provare che una consegna ripetuta non ripete una leaf riuscita. 7. Testare upgrade, migrazione dello storage, entry point legacy disabilitati, rotazione dei peer, fork è recupero; riconciliare receipt, eventi, stato processed è saldi di destinazione. ## Esempi - **Vincolo al dominio di destinazione.** Due istruzioni hanno nonce `42` è valore `1,000`, ma una mira alla chain `10` è l'altra alla chain `8453`. Un identificatore che omette la destinazione tratta `2 messages` come candidate alla collisione; l'encoding canonico che la vincola genera `2 distinct IDs`. Hash è rappresentazione del dominio dipendono dal protocollo. - **Bitmap non ordinato.** Per nonce `513`, `word = floor(513 / 256) = 2`, `bit = 513 mod 256 = 1` è `mask = 1 << 1 = 2`. Il primo successo cambia la word `2` da `0` a `2`. Un duplicato trova `2 & 2 = 2` è viene rifiutato; nonce `512` usa indipendentemente il bit `0`. - **Il retry non è un secondo effetto.** Lo stesso messaggio viene consegnato `3` volte. Chiamate con `110,000` è `125,000` gas falliscono è fanno revert; la terza usa `140,000` gas è riesce una volta. Il gas totale è `110,000 + 125,000 + 140,000 = 375,000`; a `20 gwei` equivale a `0.0075 ETH`. Le consegne sono `3`, gli effetti commerciali riusciti `1`. - **Contabilita di batch parziale.** Quattro leaf eseguibili separatamente contengono `25 + 40 + 15 + 20 = 100` unità. Le leaf `0`, `1` è `3` eseguono `25 + 40 + 20 = 85`; la leaf `2` fallisce è lascia `15` in sospeso. Consumare solo la root blocca le `15`; ripetere tutto senza stato per leaf può duplicare le `85`. Occorre rollback atomico o stato processed per leaf. ## Rischi - L'identificatore omette chain o dominio di destinazione. - L'identificatore omette messenger o emitter sorgente. - La versione del protocollo o messaggio manca dal dominio. - Un namespace di nonce collide tra mittenti o deployment. - Un encoding packed ambiguo crea collisioni tra campi diversi. - Un fork o chain ID riutilizzato rende valido un vecchio dominio. - Un evento è accettato prima di sufficiente finalità è viene riorganizzato. - Viene accettato root, set di validatori o guardian errato. - Un vecchio dominio di firma resta valido dopo un upgrade. - Corruzione dello storage del proxy azzera o sovrappone lo stato processed. - La migrazione omette consumati o lascia attivo un entry point legacy. - Lo stato viene marcato dopo la chiamata esterna, consentendo reentrancy. - Una chiamata fallita è marcata riuscita è non può essere ripetuta. - Una chiamata riuscita non persiste è ripete l'effetto economico. - Un nonce ordinato mancante blocca tutti i messaggi successivi. - L'aritmetica di word, bit o invalidazione del bitmap è errata. - Lo stato della batch root contrasta con l'esecuzione parziale delle leaf. - Un retry ripete leaf già riuscite. - Le unità di deadline, expiry o clock destinazione sono interpretate male. - L'allowlist dei relayer viene scambiata per autorizzazione del messaggio. ## Errori comuni - **Un nonce da solo è globalmente unico.** Mittente, protocollo, deployment è domini ne definiscono il namespace. - **Solo un relayer autorizzato impedisce il replay.** Il relayer consegna; verifica a destinazione è stato consumed persistente applicano autorizzazione è controllo. - **Ogni consegna ripetuta è un attacco.** Una rete at-least-once può ripetere un fallimento; l'invariante è non più di un effetto riuscito. - **Una prova o firma valida dimostra finalità è intento.** Puo omettere il target, vincolare la versione errata o attestare uno stato poi riorganizzato. - **Una transazione bridge riuscita prova exactly-once.** Verificare receipt, storage processed, eventi del destinatario è saldi reali, inclusa ogni leaf. ## Argomenti correlati - [Bridge cross-chain](/it/crypto/cross-chain-bridge/) - [Bridge canonico](/it/crypto/canonical-bridge/) - [Guasto di un relayer cross-chain](/it/crypto/bridge-relayer-liveness-risk/) ## Fonti - [ERC-5164: Cross-Chain Execution](https://eips.ethereum.org/EIPS/eip-5164) - Ethereum Improvement Proposals (consultato: 2026-08-13) - [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Improvement Proposals (consultato: 2026-08-13) - [CCTP Technical Guide](https://developers.circle.com/cctp/references/technical-guide) - Circle Developers (consultato: 2026-08-13) - [Interop message passing overview](https://docs.optimism.io/app-developers/guides/interoperability/message-passing) - Optimism Documentation (consultato: 2026-08-13) - [VAAs](https://docs.wormhole.com/protocol/infrastructure/vaas/) - Wormhole Docs (consultato: 2026-08-13) - [Security Considerations](https://docs.soliditylang.org/en/latest/security-considerations.html) - Solidity Documentation (consultato: 2026-08-13) - [Proof-of-stake (PoS)](https://ethereum.org/developers/docs/consensus-mechanisms/pos/) - ethereum.org (consultato: 2026-08-13) - [Upgrading smart contracts](https://docs.openzeppelin.com/contracts/5.x/learn/upgrading-smart-contracts) - OpenZeppelin Docs (consultato: 2026-08-13) Source: https://wiki.fcontext.com/it/crypto/bridge-message-replay-protection/index.mdx