Relay Link Bridge: cómo funciona el relay entre cadenas y cómo verificarlo

Qué es realmente un relay link bridge

La frase "relay link bridge" describe un sistema entre cadenas en el que un relayer mueve un mensaje, prueba o atestación desde una cadena de origen a una cadena de destino, y un verificador en la cadena de destino decide si esa evidencia es aceptable. El relayer es la capa de transporte; el verificador es la capa de confianza. Confundir ambas es la fuente más común de suposiciones erróneas sobre la seguridad de un puente.

Una blockchain es excelente para ponerse de acuerdo sobre su propio estado y deficiente para conocer por sí sola hechos de otra cadena. Incluso cuando un contrato de destino puede verificar una cabecera de bloque externa o un conjunto de firmas, alguien debe obtener esa cabecera, ensamblar el payload y pagar gas para enviarlo. Ese alguien es el relayer. Si no aparece ningún relayer, el puente puede seguir siendo seguro pero deja de ser útil, porque la disponibilidad vive fuera de la cadena aunque la seguridad resida en la cadena.

Este artículo cubre el modelo general de relay link bridge en lugar de respaldar un producto específico. Puentes con nombre como Relay, Wormhole, LayerZero y sistemas basados en IBC implementan el modelo de manera diferente, y debes leer la documentación propia de cada protocolo para conocer sus supuestos de confianza exactos. Lo que sigue es un modelo mental, un procedimiento de diagnóstico y un método de medición que puedes aplicar a cualquiera de ellos.

• Relayer: observa eventos de la cadena de origen, empaqueta evidencia, envía transacciones a la cadena de destino.
• Verificador: cliente ligero, conjunto de validadores, comité de guardianes u oráculo que decide la validez.
• Ejecutor o solver: en diseños basados en intenciones, adelanta liquidez y es reembolsado tras la verificación.
• Aplicación de usuario: la "interfaz" o aplicación web que construye la transacción de origen.

Supuestos y requisitos previos antes de rastrear una transferencia

Para seguir una transacción de puente de extremo a extremo necesitas acceso de lectura tanto a la cadena de origen como a la de destino, el hash de la transacción de origen y las direcciones del contrato del puente en cada lado. No necesitas una billetera con fondos para rastrear, pero sí necesitas un endpoint RPC confiable por cadena. Los endpoints públicos sirven para una consulta puntual; para diagnósticos repetidos o monitoreo de relayers, usa un proveedor gestionado. La guía de endpoints RPC multicadena de OnFinality explica cómo estructurar el acceso a endpoints en varias redes, y el directorio de redes lista las cadenas disponibles.

Registra cuatro datos antes de empezar: el ID de la cadena de origen, el ID de la cadena de destino, el hash de la transacción de origen y la dirección del contrato del puente en la cadena de destino. Sin la dirección del contrato de destino no puedes filtrar logs eficientemente, y sin ambos IDs de cadena no puedes confirmar que el relayer envió a la cadena que esperas.

La tubería de relay: observar, empaquetar, enviar, verificar

Todo relay link bridge sigue la misma tubería de cuatro etapas, incluso cuando los detalles de implementación difieren.

Observar. El relayer vigila los logs de la cadena de origen en busca de eventos emitidos por el contrato del puente, como un depósito, bloqueo o evento de mensaje enviado. Debe rastrear la finalidad: un depósito que luego es revertido por una reorganización no debe retransmitirse. Por eso los relayers esperan una profundidad de confirmación que varía según la cadena.

Empaquetar. El relayer ensambla la evidencia que necesita el verificador de destino. En un puente de cliente ligero, esto es una cabecera de bloque más una prueba de Merkle. En un puente de atestación, es un conjunto de firmas de un comité de guardianes o validadores. En un diseño basado en oráculos, puede ser una atestación de precio o estado producida por una red separada.

Enviar. El relayer envía una transacción a la cadena de destino que transporta el payload y paga el gas por ella. Algunos diseños permiten que cualquiera envíe y recompensan al remitente; otros restringen el envío a un conjunto permitido.

Verificar y ejecutar. El contrato de destino comprueba la evidencia contra su estado almacenado y luego acuña, desbloquea o ejecuta el mensaje. Solo este paso decide la validez. La opinión del relayer nunca lo hace.

• Frontera de seguridad: el contrato verificador y sus supuestos de confianza.
• Frontera de disponibilidad: el conjunto de relayers y sus incentivos.
• Frontera de finalidad: la profundidad de confirmación que el relayer espera en la cadena de origen.

Rastrear una transferencia de puente con llamadas RPC

La forma más rápida de entender un relay link bridge es observar una transacción cruzarlo. Empieza leyendo el recibo de la transacción de origen y extrayendo el evento del puente. La siguiente llamada curl usa un endpoint de marcador de posición; sustituye tu propio RPC_URL para la cadena de origen.

• Verifica que el estado sea 0x1 antes de confiar en cualquier log.
• Anota el blockNumber; lo necesitarás para confirmar la profundidad de finalidad.
• Identifica la dirección del contrato del puente entre los emisores de logs.
• Decodifica el primer tema para confirmar que coincide con la firma de evento documentada del puente.

curl -s -X POST "$RPC_URL" \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "eth_getTransactionReceipt",
    "params": ["0xSOURCE_TX_HASH"]
  }'

Encontrar la transacción de destino correspondiente

Una vez que tengas el evento de origen, busca en la cadena de destino el envío del relayer. El método más confiable es filtrar los logs de destino por la dirección del contrato del puente y el identificador de mensaje emitido en la cadena de origen. El siguiente JavaScript usa un cliente JSON-RPC estándar y valores de marcador de posición.

• Si el rango de logs es enorme, reduce fromBlock usando la marca de tiempo de la transacción de origen.
• Si no aparecen logs, puede que el relayer aún no haya enviado, o que la firma del evento sea diferente.
• Confirma el estado de la transacción de destino con un recibo antes de concluir que fue exitosa.

import { createPublicClient, http, parseAbiItem } from 'viem';

const dest = createPublicClient({ transport: http(process.env.DEST_RPC_URL) });
const event = parseAbiItem(
  'event MessageReceived(bytes32 indexed messageId, address indexed recipient)'
);

const logs = await dest.getLogs({
  address: '0xDESTINATION_BRIDGE_CONTRACT',
  event,
  args: { messageId: '0xSOURCE_MESSAGE_ID' },
  fromBlock: 0n,
  toBlock: 'latest'
});

for (const log of logs) {
  console.log(log.transactionHash, log.blockNumber);
}

Resultado de verificación esperado y qué demuestra

Un rastreo exitoso produce un recibo de origen con estado 0x1, un evento de origen decodificado que contiene un identificador de mensaje y un recibo de destino con estado 0x1 cuyos logs contienen el mismo identificador. Esa cadena de evidencia demuestra que el relayer transportó el mensaje y que el verificador de destino lo aceptó. No demuestra que el puente no requiera confianza; eso depende de lo que verificó el verificador.

Registra las marcas de tiempo de ambos bloques y la diferencia entre ellas. Ese delta es la latencia de relay observada para esta transferencia, y es el número que debes comparar con las expectativas documentadas del puente. No generalices a partir de una sola transacción; recopila una muestra antes de sacar conclusiones.

• Estado de origen 0x1 y estado de destino 0x1.
• Identificador de mensaje coincidente en ambos lados.
• La marca de tiempo del bloque de destino menos la del bloque de origen es igual a la latencia observada.
• Tipo de verificador identificado a partir del diseño documentado del contrato de destino.

Medir la capa RPC de la que dependen los relayers

Los relayers son clientes con un uso intensivo de RPC: consultan logs, leen cabeceras y envían transacciones continuamente. Si tu propia integración o monitoreo depende de un relay link bridge, mide los endpoints RPC que usas en lugar de asumir las afirmaciones de marketing del proveedor. El procedimiento a continuación produce una tabla de resultados que tú mismo completas; aquí no se proporcionan números porque dependen de tu región, cadena y endpoint.

Para cada endpoint candidato, ejecuta un número fijo de solicitudes durante una ventana fija y registra las métricas en la tabla. Usa el mismo método para cada endpoint para que la comparación sea justa.

• | Endpoint | Cadena | Latencia p50 (ms) | Latencia p95 (ms) | Tasa de error | Retraso máximo de bloque |
• | RPC_URL_A | origen | medir | medir | medir | medir |
• | RPC_URL_B | destino | medir | medir | medir | medir |
• Retraso de bloque: compara eth_blockNumber con un nodo de referencia o la altura del explorador.
• Ejecuta la prueba a la misma hora del día para cada endpoint para reducir el sesgo diurno.

import time, statistics, requests

RPC_URL = "https://your-endpoint.example"
N = 50
latencies = []
errors = 0

for _ in range(N):
    start = time.perf_counter()
    try:
        r = requests.post(RPC_URL, json={
            "jsonrpc": "2.0", "id": 1,
            "method": "eth_blockNumber", "params": []
        }, timeout=5)
        r.raise_for_status()
        r.json()["result"]
    except Exception:
        errors += 1
    latencies.append((time.perf_counter() - start) * 1000)

latencies.sort()
print("p50_ms", statistics.median(latencies))
print("p95_ms", latencies[int(len(latencies) * 0.95) - 1])
print("error_rate", errors / N)

Solución de problemas de relays estancados o desajustados

La mayoría de los problemas de relay caen en un pequeño número de categorías. Revísalos en orden en lugar de adivinar.

No hay transacción de destino. Puede que el relayer aún esté esperando la finalidad de origen, que no tenga fondos suficientes para el gas o que haya descartado el mensaje. Primero verifica la profundidad de confirmación de origen contra el requisito documentado del puente.

La transacción de destino se revirtió. Lee el motivo de reversión si el contrato lo expone. Las causas comunes son un plazo de mensaje expirado, una protección contra repetición que rechaza un duplicado o un verificador que rechaza evidencia que no coincidía con su estado almacenado.

Discrepancia en el identificador de mensaje. Si el log de destino existe pero el identificador difiere, puede que estés decodificando el evento incorrecto o mirando una ruta de puente diferente. Confirma la dirección del contrato y la firma del evento con la documentación del protocolo.

Inconsistencia de RPC. Si un endpoint reporta un evento de origen y otro no, es probable que estés leyendo un nodo retrasado. Compara las alturas de bloque y vuelve a consultar después de que el endpoint retrasado se ponga al día.

• Confirma la profundidad de finalidad de origen antes de asumir una falla del relayer.
• Verifica el saldo de gas del relayer si el diseño usa envío sin permisos.
• Asegúrate de consultar el contrato del puente correcto en cada cadena.
• Vuelve a ejecutar las consultas de logs contra un segundo endpoint para descartar retraso del nodo.

Limitaciones y compensaciones del modelo de relay

Los relay link bridges intercambian algo de descentralización por velocidad y costo. Los relayers fuera de cadena pueden responder en segundos, pero añaden una dependencia de disponibilidad y, en diseños de atestación, una dependencia de confianza en el comité firmante. Los puentes de cliente ligero reducen la confianza pero aumentan los costos de gas en la cadena de destino porque la verificación ocurre en cadena.

Los supuestos de finalidad importan tanto como la criptografía. Un relayer que envía antes de la finalidad de origen corre el riesgo de retransmitir una transacción que luego desaparece en una reorganización. Un relayer que espera demasiado es seguro pero lento. Cada puente elige un punto en esa curva, y los integradores deben saber dónde se sitúa su puente.

Por último, la "interfaz" de usuario no es el protocolo. Una aplicación web puede no estar disponible mientras los contratos y relayers subyacentes siguen operando, y lo contrario también es cierto. Diagnostica a nivel de contrato y relayer, no a nivel de interfaz.

Próximos pasos para integradores y operadores

Si estás integrando un relay link bridge en una billetera o flujo de pago, empieza documentando el tipo de verificador y el requisito de finalidad para cada ruta que soportas. Luego construye un monitor que rastree eventos de origen hasta recibos de destino usando el procedimiento anterior, y alerta cuando la latencia observada supere tu umbral.

Para la capa RPC, ejecuta el procedimiento de medición contra cada endpoint de tu conjunto de failover y mantén actualizada la tabla de resultados. Si necesitas rendimiento dedicado para la infraestructura del relayer, revisa las opciones de nodo dedicado y los precios de RPC antes de comprometerte. Para recomendaciones concretas de endpoints y proveedores por red, RPC Assistant cubre eso directamente; esta página se centra en el mecanismo de relay y el método de medición. También puedes revisar la descripción general del servicio API para entender cómo el acceso gestionado encaja junto a tu propio stack de relayers.

• Documenta el tipo de verificador y la profundidad de finalidad por ruta.
• Construye un monitor de rastreo de origen a destino con alertas de latencia.
• Mantén una tabla de resultados RPC actualizada para cada endpoint de failover.
• Vuelve a probar después de cualquier actualización del contrato del puente o cambio en el conjunto de relayers.