Vai al contenuto
Financial Context Wiki

Rischio di disponibilità del relayer cross-chain

Rischio che un messaggio autenticato non sia consegnato o eseguito in tempo; la diagnosi separa finalità, prova, consegna, esecuzione e contabilità.

Aggiornato

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

Fonti

Navigazione

Cerca nella wiki...