--- title: "Rischio di disponibilità del relayer cross-chain" description: "Rischio che un messaggio autenticato non sia consegnato o eseguito in tempo; la diagnosi separa finalità, prova, consegna, esecuzione e contabilità." 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. # Rischio di disponibilità del relayer cross-chain > Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite. ## Risposta diretta Il rischio di disponibilità del relayer cross-chain è che un messaggio valido e autenticato non venga presentato o eseguito in tempo sulla destinazione. Il relayer trasporta messaggio e proof o metadata; non rende finale l'evento sorgente né autorizza il payload. Consenso sorgente, produzione di proof o attestazione, verifica a destinazione ed esecuzione del receiver sono dipendenze separate. Il ritardo è inizialmente un problema di disponibilità, non prova di furto. Può comunque causare costo finanziario, scadenze mancate, ticket scaduti, liquidità inutilizzabile o perdita permanente. Receipt sorgente ed etichetta `Pending` non provano un guasto del relayer: la sorgente può non essere finalizzata, la prova assente, la destinazione in pausa, il gas insufficiente o il receiver può fare revert. La consegna permissionless dipende dal protocollo. Hyperlane e Wormhole descrivono percorsi aperti a terzi; altri deployment limitano executor, destination caller o recovery. L'invio aperto non consente di modificare un payload autenticato, e una allowlist di relayer non sostituisce verifica né replay protection. ## Come funziona Un ciclo analitico separa `source submitted`, `source finalized`, `proof pending`, `ready`, `destination submitted`, `failed/retryable`, `executed` e `expired/cancelled`. Sono etichette analitiche; ogni protocollo ha campi propri. Withdrawal OP Stack, messaggio burn-and-mint CCTP, VAA Wormhole e messaggio Hyperlane hanno regole diverse per prove, tempi, fee e retry. Prima si accerta se l'azione sorgente ha bloccato, bruciato o inviato valore e raggiunto la finalità richiesta. Poi si verifica che root, firme dei validatori, VAA dei guardian o attestation siano disponibili e correnti. Solo allora si controlla se il relayer ha osservato il messaggio, accettato la fee policy, costruito metadata corretti e inviato al contratto esatto. L'esecuzione a destinazione ha errori indipendenti: outage di chain o sequencer, RPC obsoleto, pausa, versione receiver errata, gas insufficiente, blocco da nonce ordinato, expiry o revert applicativo. Un hash è solo riferimento di invio. Il completamento richiede receipt riuscita, stato processed, evento o modifica del receiver, token corretto ed effetto sul saldo sotto la finalità richiesta. Il relay manuale non è un rimedio universale. È possibile solo se il deployment espone un entry point idoneo, messaggio e prova originali sono reperibili, il caller è autorizzato, il messaggio non è consumato o scaduto e si possono finanziare gas e valore. Simulare la chiamata ufficiale. Non creare un nuovo lock o burn sorgente per riparare un primo messaggio non diagnosticato. Retry e replay sono diversi. Un retry documentato ripresenta lo stesso messaggio canonico dopo un effetto fallito; stato consumed o nonce corretto permette al massimo un successo. Più relayer possono competere e consumare gas mentre la replay protection mantiene la sicurezza. Annullare un task locale non ritira una transazione già trasmessa o inclusa. Usare questo flusso: 1. Fissare protocollo, lane, versione, domini e contratti, transazione e log sorgente, ID o nonce, azione asset, raw amount, receiver ed expiry. 2. Verificare receipt ed evento sorgente e applicare conferme o finalità; controllare identità del blocco e reorg invece dell'interfaccia. 3. Trovare proof, VAA, attestation, checkpoint o root; verificare stato sorgente, versione, signer set, disponibilità e invalidazione o expiry. 4. Verificare salute del target, versioni messenger/receiver, pausa, nonce o processed state, predecessori, deadline e gas nativo. 5. Determinare se la consegna è permissionless, allowlisted o ristretta; per il percorso manuale ricostruire e simulare payload, proof e chiamata originali. 6. Aggiornare gas limit, price, markup di cambio, fee cap, refund ed expiry; inviare o ripetere lo stesso messaggio, gestire duplicate/replacement race e conservare il receipt. 7. Riconciliare escrow o burn, passività in-flight, mint, unlock o call, fee, refund e stato finale; usare canali documentati senza seed phrase o private key. ## Esempi - **Attribuire il ritardo.** Finalità sorgente `12 minutes`, proof `8 minutes`, coda relayer `35 minutes`, inclusione `5 minutes`. Totale `12 + 8 + 35 + 5 = 60 minutes`. Solo la coda `35-minute` è delivery liveness; primi `20 minutes` e ultimi `5 minutes` hanno altri responsabili. - **Gas quote insufficiente.** Limite `300,000`. A `25 gwei`: `300,000 * 25 * 10^-9 = 0.0075 ETH`. In esecuzione, `60 gwei` richiede `0.018 ETH`, deficit `0.018 - 0.0075 = 0.0105 ETH`. Più gas sorgente non finanzia necessariamente il target. - **Relayer duplicati spendono gas, non principal.** Tre inviano lo stesso messaggio da `100,000 USDC`. Il vincitore usa `180,000 gas * 30 gwei = 0.0054 ETH`; due fanno revert dopo `70,000 gas * 30 gwei = 0.0021 ETH` ciascuno. Totale `0.0054 + 0.0021 + 0.0021 = 0.0096 ETH`; corretto replay state consente `100,000 USDC`, non `300,000 USDC`. - **Passività in transito.** Una rotta lock-and-mint blocca `25 ETH`; dopo il fallimento: escrow `+25 ETH`, wrapped supply `+0 ETH`, passività in-flight `25 ETH`. Retry riuscito lascia escrow `25 ETH`, porta supply a `25 ETH` e passività a `0 ETH`. Un nuovo deposito di `25 ETH` creerebbe `50 ETH` di escrow e due obbligazioni. ## Rischi - Transazione sorgente pending o revert mentre l'interfaccia dice inviata. - Evento usato prima di sufficiente finalità. - Reorg rimuove o cambia l'evento. - Proof, attestation, checkpoint o firme non disponibili. - Root o signer set obsoleto, errato o invalidato. - Chiave o servizio relayer allowlisted indisponibile. - Permissionless confuso con consegna puntuale garantita. - Entry point ristretto confuso con percorso manuale pubblico. - Chain, sequencer, RPC o indexer target indisponibile o obsoleto. - Messenger o receiver target in pausa. - Upgrade o address mismatch del receiver causa revert. - Gas limit target troppo basso. - Gas quote, cambio, fee cap o refund obsoleto. - Wallet privo del corretto asset gas nativo. - Messaggio, ticket, proof o deadline scade. - Gap di nonce ordinato blocca messaggi successivi. - Logica retry/consumed duplica o impedisce recovery. - Race di duplicazione, cancellazione o replacement consuma gas. - Supporto falso fornisce contratti, prove o calldata dannosi. - Lock/burn, claim in-flight, effetti, fee e refund mal riconciliati. ## Errori comuni - **Il relayer autentica il messaggio.** La consegna porta evidenza; verifier e applicazione target applicano source, sender, payload e replay. - **Outage significa perdita o refund automatico.** Prima causa ritardo; expiry, recovery, solvibilità e refund dipendono dal prodotto. - **Permissionless consente modifiche o garantisce esecuzione immediata.** Autenticazione impedisce modifiche; proof, gas, chain e receiver regolano liveness. - **Ogni retry duplica il mint.** Il retry corretto riusa un messaggio e permette un effetto; un nuovo transfer crea una nuova obbligazione. - **Hash target o label completed prova ricezione.** Verificare receipt, processed state, eventi, saldi, token e finalità. ## Argomenti correlati - [Bridge cross-chain](/it/crypto/cross-chain-bridge/) - [Protezione dal replay dei messaggi](/it/crypto/bridge-message-replay-protection/) - [Bridge canonico](/it/crypto/canonical-bridge/) ## Fonti - [Relayer](https://docs.hyperlane.xyz/docs/protocol/agents/relayer) - Hyperlane Documentation (consultato: 2026-08-13) - [Mailbox](https://docs.hyperlane.xyz/docs/protocol/core/mailbox) - Hyperlane Documentation (consultato: 2026-08-13) - [VAAs](https://docs.wormhole.com/protocol/infrastructure/vaas/) - Wormhole Docs (consultato: 2026-08-13) - [Executor Framework](https://docs.wormhole.com/protocol/infrastructure/relayers/executor-framework/) - Wormhole Docs (consultato: 2026-08-13) - [Withdrawals](https://specs.optimism.io/protocol/withdrawals.html) - OP Stack Specification (consultato: 2026-08-13) - [Cross Domain Messengers](https://specs.optimism.io/protocol/messengers.html) - OP Stack Specification (consultato: 2026-08-13) - [CCTP Technical Guide](https://developers.circle.com/cctp/references/technical-guide) - Circle Developers (consultato: 2026-08-13) - [Proof-of-stake (PoS)](https://ethereum.org/developers/docs/consensus-mechanisms/pos/) - ethereum.org (consultato: 2026-08-13) Source: https://wiki.fcontext.com/it/crypto/bridge-relayer-liveness-risk/index.mdx