Saltar al contenido
Financial Context Wiki

Riesgo de disponibilidad de relayers entre cadenas

Es el riesgo de que un mensaje autenticado no se entregue o ejecute a tiempo; el diagnostico separa finalidad de origen, disponibilidad de prueba, entrega, ejecucion y contabilidad.

Actualizado

Solo con fines educativos; no constituye asesoramiento de inversión. Invertir puede ocasionar pérdidas.

Respuesta directa

El riesgo de disponibilidad de un relayer entre cadenas es que un mensaje válido y autenticado no se presente o ejecute a tiempo en su destino. El relayer normalmente transporta el mensaje y su prueba o metadata; no vuelve final el evento de origen ni autoriza el payload. Consenso de origen, producción de prueba o attestación, verificación de destino y ejecución del receiver son dependencias separadas.

Un retraso de entrega es inicialmente un problema de disponibilidad, no prueba de robo. Aun así puede generar coste financiero, plazos perdidos, tickets vencidos, liquidez inutilizable o pérdida permanente según el producto. A la inversa, un receipt de origen y la etiqueta Pending no prueban que falle el relayer: el origen puede no ser final, faltar la prueba, estar pausado el destino, faltar gas o revertir el receiver.

La entrega permissionless depende del protocolo. Hyperlane y Wormhole describen rutas donde terceros entregan mensajes autenticados; otros deployments restringen executors, destination callers o funciones de recuperación. La presentación abierta no permite modificar un payload autenticado, y una allowlist de relayers no sustituye la verificación ni la protección contra replay.

Cómo funciona

Un ciclo analítico útil separa source submitted, source finalized, proof pending, ready, destination submitted, failed/retryable, executed y expired/cancelled. Cada protocolo usa sus propios campos on-chain. Un withdrawal de OP Stack, un mensaje burn-and-mint de CCTP, una VAA de Wormhole y un mensaje Hyperlane tienen reglas distintas de prueba, tiempo, tarifas y retry.

Primero se confirma si la acción de origen bloqueó, quemó o despachó valor y alcanzó la finalidad exigida. Después se comprueba que estén disponibles y vigentes la root, firmas de validadores, VAA de guardians o attestation esperadas. Solo entonces se pregunta si el relayer observó el mensaje, aceptó su política de tarifas, construyó metadata correcta y la envió al contrato de destino exacto.

La ejecución de destino tiene fallos independientes: caída de chain o sequencer, RPC obsoleto, pausa contractual, versión incorrecta del receiver, gas insuficiente, bloqueo por nonce ordenado, expiry o revert de la aplicación. Un hash de transacción solo referencia una presentación. Completar exige receipt correcto, estado processed, evento o cambio del receiver, token correcto y efecto de saldo esperado bajo la finalidad requerida.

El relay manual no es un botón universal de rescate. Solo es posible si el protocolo desplegado ofrece un entry point apto, se obtienen mensaje y prueba originales, el caller está permitido, el mensaje sigue sin consumir y sin vencer, y se puede financiar gas y valor de destino. Simule la llamada oficial. Nunca cree otro lock o burn de origen para reparar un primer mensaje sin diagnosticar.

Retry y replay son distintos. Un retry documentado vuelve a presentar el mismo mensaje canónico tras fallar el efecto de destino; el estado consumed o nonce correcto permite como máximo un efecto exitoso. Varios relayers pueden competir y gastar gas aunque replay protection mantenga la seguridad. Cancelar una tarea local no retira una transacción de destino ya difundida o incluida.

Use este flujo:

  1. Fije protocolo, lane y versión, dominios y contratos, transacción y log de origen, ID o nonce, acción sobre el activo, raw amount, receiver y expiry.
  2. Verifique receipt y evento de origen y aplique la regla de confirmación o finalidad; revise identidad del bloque y reorg en vez de confiar en la interfaz.
  3. Localice proof, VAA, attestation, checkpoint o root definidos; compruebe estado fuente, versión, signer set, disponibilidad e invalidación o expiry.
  4. Revise salud del destino, versiones de messenger y receiver, pausa, nonce o processed state, requisitos previos, deadline y gas nativo.
  5. Determine si la entrega es permissionless, allowlisted o restringida; para una ruta manual apta, reconstruya y simule payload, prueba y llamada oficiales originales.
  6. Actualice gas limit, price, recargo de tipo de cambio, fee cap, refund y expiry; presente o reintente el mismo mensaje, gestione carreras de duplicación/replacement y conserve el receipt.
  7. Concilie escrow o burn, pasivo in-flight, mint, unlock o call, tarifas, refunds y estado final; escale por canales documentados sin compartir seed phrase ni private key.

Ejemplos

  • Atribución del retraso. La finalidad tarda 12 minutes, la prueba 8 minutes, la cola del relayer 35 minutes y la inclusión destino 5 minutes. Total: 12 + 8 + 35 + 5 = 60 minutes. Solo la cola de 35-minute corresponde a delivery liveness; los primeros 20 minutes y últimos 5 minutes tienen otros responsables.
  • Cotización de gas insuficiente. El límite es 300,000. A 25 gwei, cuesta 300,000 * 25 * 10^-9 = 0.0075 ETH. Al ejecutar, 60 gwei exige 0.018 ETH, con déficit 0.018 - 0.0075 = 0.0105 ETH. Pagar más gas de origen no necesariamente financia el destino.
  • Relayers duplicados gastan gas, no principal. Tres presentan el mismo mensaje de 100,000 USDC. El ganador usa 180,000 gas * 30 gwei = 0.0054 ETH; dos fallan tras 70,000 gas * 30 gwei = 0.0021 ETH cada uno. Gas total: 0.0054 + 0.0021 + 0.0021 = 0.0096 ETH; replay state correcto permite un efecto de 100,000 USDC, no 300,000 USDC.
  • Pasivo en tránsito. Una ruta lock-and-mint bloquea 25 ETH; al fallar destino, escrow es +25 ETH, wrapped supply +0 ETH y pasivo in-flight 25 ETH. El retry correcto mantiene escrow en 25 ETH, eleva supply a 25 ETH y reduce el pasivo a 0 ETH. Otro depósito fuente de 25 ETH crearía 50 ETH de escrow y dos obligaciones.

Riesgos

  • La transacción de origen sigue pending o revierte mientras la interfaz dice enviada.
  • Se actúa sobre un evento antes de suficiente finalidad.
  • Una reorg elimina o cambia el evento.
  • No están disponibles proof, attestation, checkpoint o firmas.
  • Se usa una root o signer set obsoleto, incorrecto o invalidado.
  • Una clave o servicio de relayer allowlisted queda indisponible.
  • Permissionless se confunde con entrega puntual garantizada.
  • Un entry point restringido se confunde con una ruta manual pública.
  • Chain, sequencer, RPC o indexer destino está caído u obsoleto.
  • Messenger o receiver destino está pausado.
  • Upgrade o address mismatch del receiver hace revertir la llamada.
  • Gas limit de destino demasiado bajo.
  • Gas quote, tipo de cambio, fee cap o refund queda obsoleto.
  • La wallet carece del activo de gas nativo correcto.
  • Vence mensaje, ticket, proof o deadline de ejecución.
  • Un hueco de nonce ordenado bloquea mensajes posteriores.
  • La lógica retry/consumed duplica o impide recuperar.
  • Carreras de envío duplicado, cancelación o replacement gastan gas.
  • Soporte falso aporta contratos, pruebas o calldata maliciosos.
  • Se concilian mal lock/burn, claims in-flight, efectos, fees y refunds.

Errores comunes

  • El relayer autentica el mensaje. La entrega lleva evidencia; verifier y aplicación destino aplican reglas de origen, sender, payload y replay.
  • Una caída implica pérdida o refund automático. Primero causa retraso; expiry, recuperación, solvencia y refund dependen del producto.
  • Permissionless permite cambiar el payload o garantiza ejecución inmediata. La autenticación impide cambios; proof, gas, chain y receiver gobiernan la disponibilidad.
  • Todo retry duplica el mint. El retry correcto reutiliza un mensaje y solo admite un efecto; una nueva transferencia origen crea otra obligación.
  • Un hash destino o etiqueta completed prueba recepción. Confirme receipt, processed state, eventos, balances, token y finalidad.

Temas relacionados

Fuentes

Navegación

Buscar en la wiki...