Aller au contenu
Financial Context Wiki

Risque de disponibilité des relayers inter-chaînes

Risque qu'un message authentifié ne soit pas livré ou exécuté à temps ; le diagnostic sépare finalité, preuve, livraison, exécution et comptabilité.

Mis à jour

À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.

Réponse directe

Le risque de disponibilité d’un relayer inter-chaînes est qu’un message valide et authentifié ne soit pas soumis ou exécuté à temps sur sa destination. Le relayer transporte généralement le message et sa preuve ou metadata ; il ne finalise pas l’événement source et n’autorise pas le payload. Consensus source, production de preuve ou attestation, vérification cible et exécution du receiver sont des dépendances distinctes.

Un retard est d’abord un problème de disponibilité, pas une preuve de vol. Il peut néanmoins produire coût de financement, échéances manquées, tickets expirés, liquidité inutilisable ou perte définitive. À l’inverse, un receipt source et le label Pending ne prouvent pas une panne du relayer : source non finale, preuve absente, destination en pause, gas sous-financé ou receiver en revert sont possibles.

La livraison permissionless dépend du protocole. Hyperlane et Wormhole décrivent des voies où des tiers livrent des messages authentifiés ; d’autres deployments limitent executor, destination caller ou fonctions de recovery. Une soumission ouverte ne permet pas d’altérer un payload authentifié, et une allowlist de relayers ne remplace ni la vérification ni la replay protection.

Fonctionnement

Un cycle analytique distingue source submitted, source finalized, proof pending, ready, destination submitted, failed/retryable, executed et expired/cancelled. Ce sont des labels analytiques ; chaque protocole possède ses champs. Withdrawal OP Stack, message burn-and-mint CCTP, VAA Wormhole et message Hyperlane diffèrent par preuve, délai, fee et retry.

Il faut d’abord établir si l’action source a verrouillé, brûlé ou envoyé de la valeur et atteint la finalité exigée. Ensuite, vérifier la disponibilité et l’actualité de la root, des signatures de validateurs, de la VAA des guardians ou de l’attestation. Alors seulement, vérifier que le relayer a observé le message, accepté sa fee policy, construit la bonne metadata et soumis au contrat exact.

L’exécution cible a ses propres échecs : panne de chain ou sequencer, RPC obsolète, pause, mauvaise version du receiver, gas insuffisant, blocage par nonce ordonné, expiry ou revert applicatif. Un hash ne référence qu’une soumission. L’achèvement exige receipt réussi, état processed, événement ou changement du receiver, bon token et effet attendu sur le solde sous la finalité requise.

Le relay manuel n’est pas un bouton de secours universel. Il n’est possible que si le deployment expose un entry point éligible, si message et preuve originaux sont accessibles, si le caller est autorisé, si le message reste non consommé et non expiré et si gas et valeur cible peuvent être financés. Simuler l’appel officiel. Ne jamais créer un nouveau lock ou burn source pour réparer un premier message non diagnostiqué.

Retry et replay sont distincts. Un retry documenté soumet de nouveau le même message canonique après échec de l’effet cible ; état consumed ou nonce correct autorise au plus un succès. Plusieurs relayers peuvent concourir et consommer du gas sans compromettre la sécurité. Annuler une tâche locale ne rappelle pas une transaction cible déjà diffusée ou incluse.

Suivre ce processus :

  1. Fixer protocole, lane, version, domaines et contrats, transaction et log source, ID ou nonce, action de l’actif, raw amount, receiver et expiry.
  2. Vérifier receipt et événement source, puis appliquer la règle de confirmation ou finalité ; examiner identité du bloc et reorg plutôt que l’interface.
  3. Trouver proof, VAA, attestation, checkpoint ou root ; vérifier état source, version, signer set, disponibilité et invalidation ou expiry.
  4. Vérifier santé cible, versions messenger/receiver, pause, nonce ou processed state, prédécesseurs, deadline et gas natif requis.
  5. Déterminer si la livraison est permissionless, allowlisted ou restreinte ; pour une voie manuelle, reconstruire et simuler payload, preuve et appel officiels originaux.
  6. Actualiser gas limit, price, marge de change, fee cap, refund et expiry ; soumettre ou retenter le même message, gérer courses duplicate/replacement et conserver le receipt.
  7. Rapprocher escrow ou burn, passif in-flight, mint, unlock ou call, fees, refunds et état final ; escalader par les voies documentées sans partager seed phrase ni private key.

Exemples

  • Attribuer le retard. Finalité source 12 minutes, preuve 8 minutes, file du relayer 35 minutes, inclusion cible 5 minutes. Total : 12 + 8 + 35 + 5 = 60 minutes. Seule la file 35-minute relève de delivery liveness ; les premières 20 minutes et dernières 5 minutes ont d’autres responsables.
  • Gas quote insuffisante. Limite 300,000. À 25 gwei : 300,000 * 25 * 10^-9 = 0.0075 ETH. À l’exécution, 60 gwei exige 0.018 ETH, soit un manque de 0.018 - 0.0075 = 0.0105 ETH. Plus de gas source ne finance pas nécessairement la cible.
  • Des relayers en doublon dépensent du gas, pas le principal. Trois soumettent le message de 100,000 USDC. Le gagnant utilise 180,000 gas * 30 gwei = 0.0054 ETH ; deux revert après 70,000 gas * 30 gwei = 0.0021 ETH chacun. Total 0.0054 + 0.0021 + 0.0021 = 0.0096 ETH ; un replay state correct autorise 100,000 USDC, pas 300,000 USDC.
  • Suivre le passif en transit. Une route lock-and-mint verrouille 25 ETH ; après échec : escrow +25 ETH, wrapped supply +0 ETH, passif in-flight 25 ETH. Le retry réussi laisse escrow à 25 ETH, porte supply à 25 ETH et passif à 0 ETH. Un nouveau dépôt de 25 ETH créerait 50 ETH d’escrow et deux obligations.

Risques

  • Transaction source pending ou en revert alors que l’interface dit envoyée.
  • Événement utilisé avant une finalité suffisante.
  • Reorg qui supprime ou modifie l’événement.
  • Proof, attestation, checkpoint ou signatures indisponibles.
  • Root ou signer set obsolète, erroné ou invalidé.
  • Clé ou service relayer allowlisted indisponible.
  • Permissionless confondu avec une livraison ponctuelle garantie.
  • Entry point restreint confondu avec une voie manuelle publique.
  • Chain, sequencer, RPC ou indexer cible indisponible ou obsolète.
  • Messenger ou receiver cible en pause.
  • Upgrade ou address mismatch du receiver provoquant un revert.
  • Gas limit cible trop bas.
  • Gas quote, change, fee cap ou hypothèse de refund obsolète.
  • Wallet sans le bon actif de gas natif cible.
  • Message, ticket, proof ou execution deadline expiré.
  • Trou de nonce ordonné bloquant les messages suivants.
  • Logique retry/consumed qui duplique ou empêche la recovery.
  • Courses de doublon, cancellation ou replacement consommant du gas.
  • Faux support fournissant contrats, preuves ou calldata malveillants.
  • Mauvais rapprochement lock/burn, claims in-flight, effets, fees et refunds.

Idées reçues

  • Le relayer authentifie le message. La livraison porte la preuve ; verifier et application cible appliquent source, sender, payload et replay.
  • Une panne signifie perte ou refund automatique. Elle cause d’abord un retard ; expiry, recovery, solvabilité et refund dépendent du produit.
  • Permissionless autorise la modification ou garantit l’exécution immédiate. L’authentification empêche l’altération ; proof, gas, chain et receiver gouvernent la disponibilité.
  • Tout retry duplique le mint. Le bon retry réutilise un message et permet un effet ; un nouveau transfert source crée une autre obligation.
  • Hash cible ou label completed prouve réception. Vérifier receipt, processed state, événements, soldes, token et finalité.

Sujets connexes

Sources

Navigation

Rechercher dans le wiki...