El paso de mensajes cross-chain de Hyperlane (General Message Passing, GMP) es un proceso estandarizado que se puede ejecutar de forma repetida entre cualquier cadena compatible. La aplicación llama a la función dispatch en el Mailbox de la cadena de origen para enviar un mensaje; un relayer externo (off‑chain) lo envía junto con metadatos de verificación a la cadena de destino; tras la verificación del Módulo de Seguridad Intercadena (ISM), el Mailbox llama a la función handle del contrato receptor para completar la entrega. Hyperlane (HYPER) describe el marco general de la capa de interoperabilidad de Hyperlane mediante tres componentes: Mailbox, ISM y Warp Route.
En las aplicaciones multicadena, los desarrolladores deben comprender la ruta completa desde el envío hasta la entrega del mensaje para configurar correctamente los módulos de seguridad, estimar tarifas y solucionar problemas de mensajes no entregados. ISM y Warp Route explica la división de trabajo entre los tipos de ISM (como Multifirma y Agregación) y Warp Route, y ayuda a los desarrolladores a elegir la fuerza de verificación adecuada durante la fase del proceso.
Cada mensaje entre cadenas tiene un messageId único a nivel global. El Mailbox mantiene un registro de mensajes entregados para evitar ataques de repetición. Hyperlane vs LayerZero vs Wormhole compara las diferencias estructurales entre los tres protocolos en cuanto a rutas de verificación de mensajes y permisos de implementación. El remitente paga por adelantado la tarifa de entrega de la cadena de destino en la cadena de origen mediante el Pago de Gas Intercadena (IGP); el relayer paga el gas en la cadena de destino para completar la llamada del proceso. El Explorador puede rastrear todo el ciclo de vida de un mensaje, desde el envío hasta el proceso.
¿Cuáles son las etapas del paso de mensajes entre cadenas de Hyperlane?
El flujo de mensajes entre cadenas de Hyperlane se resume en seis etapas consecutivas: envío (dispatch en la cadena de origen), escritura en el árbol Merkle, firma del validador (si el ISM lo requiere), indexación y recopilación de metadatos por parte del relayer, proceso (presentación en la cadena de destino), y verificación del ISM con handle (entrega en la cadena de destino). Este flujo no depende de una aplicación concreta ni de un evento único; cualquier contrato integrado con Mailbox puede activarlo repetidamente.
| Etapa |
Cadena |
Acción principal |
Participantes clave |
| Envío (Dispatch) |
Cadena de origen |
Codificar mensaje, escribir en árbol Merkle, emitir eventos |
Contrato remitente, Mailbox |
| Atestación (Firma) |
Origen (off-chain) |
Firmar punto de control sobre la raíz Merkle |
Validador (escenario ISM multifirma) |
| Relevo |
Fuera de cadena → Cadena de destino |
Indexar eventos, recopilar metadatos, enviar proceso |
Relayer |
| Verificar |
Cadena de destino |
Verificar origen e integridad del mensaje |
ISM |
| Entregar |
Cadena de destino |
Llamar a handle del receptor para ejecutar lógica de negocio |
Mailbox, Receptor |
La tabla anterior muestra el desglose completo de etapas del GMP de Hyperlane desde la cadena de origen hasta la cadena de destino. El envío y la entrega ocurren en los contratos Mailbox de las respectivas cadenas. Los relayers y validadores realizan funciones de transmisión fuera de cadena y atestación de seguridad, mientras que el ISM actúa como puerta de enlace de verificación de mensajes en la cadena de destino.
Figura 1. Visión general del flujo de mensajes entre cadenas de Hyperlane: ruta completa desde el envío en la cadena de origen, pasando por relayer y validador, hasta la verificación del ISM en la cadena de destino y la entrega con handle.
¿Cómo se envía un mensaje durante la fase de envío en la cadena de origen?
La fase de envío en la cadena de origen se activa cuando el contrato remitente llama a Mailbox.dispatch(). El Mailbox recibe tres parámetros principales: ID de dominio de la cadena de destino (destinationDomain), dirección del receptor (recipientAddress, codificada como bytes32) y el cuerpo del mensaje (messageBody). El Mailbox antepone un encabezado de mensaje estándar al cuerpo, que incluye campos como version, nonce, origin, sender, destination y recipient. Esto garantiza que el mensaje sea identificable de forma única y resistente a manipulaciones.
Después de ejecutar el envío, el Mailbox inserta el mensaje completo como una hoja en un árbol Merkle incremental (mantenido por el contrato MerkleTreeHook) y emite eventos Dispatch y DispatchId. El messageId es el hash keccak256 del mensaje (incluido el encabezado), devuelto por la llamada de envío y rastreable en el Explorador. El nonce es un contador que aumenta de forma monótona en el Mailbox de la cadena de origen. Incluso si el cuerpo del mensaje es idéntico, nonces diferentes generan messageId diferentes.
El remitente puede consultar la tarifa entre cadenas mediante quoteDispatch(). Esta tarifa cubre el costo del envío en la cadena de origen y el gas intercadena pagado por adelantado para la entrega en la cadena de destino. Un gancho posterior al envío (Post‑Dispatch Hook) puede pagar por adelantado el gas de la cadena de destino al relayer a través del InterchainGasPaymaster (IGP) después del envío. Una vez completado el envío, el mensaje entra en estado de espera de relevo. El messageId se genera a partir del hash del mensaje completo, y el Mailbox de la cadena de destino evita la entrega duplicada mediante la asignación delivered(messageId).
¿Cómo colaboran el relayer y el validador para entregar mensajes?
El relayer y el validador realizan funciones distintas pero complementarias en el protocolo Hyperlane. El validador es responsable de la atestación de seguridad: cuando el Mailbox de la cadena de origen envía un nuevo mensaje, el MerkleTreeHook emite un evento InsertedIntoTree. El validador lee la raíz Merkle actual, firma el punto de control y publica la firma en almacenamiento público (por ejemplo, AWS S3 o Google Cloud Storage). El relayer se encarga de la capa de transporte: escucha los eventos del Mailbox de la cadena de origen, recopila los metadatos requeridos por el ISM (por ejemplo, firmas de validadores, prueba Merkle) y llama a Mailbox.process() en la cadena de destino para enviar el mensaje.
El validador solo es necesario en escenarios de ISM multifirma o Módulo de Seguridad Económica. Si el receptor configura un ISM optimista, un ISM de prueba de conocimiento cero u otro módulo que no requiera firmas de validadores, el relayer solo necesita recopilar los metadatos que requiera ese ISM. Hyperlane no exige un conjunto de validadores establecido; el receptor puede configurar las direcciones de los validadores y el umbral de firma en el ISM multifirma por sí mismo.
El relayer consta internamente de un Indexador y un Remitente. El Indexador consulta eventos de la cadena de origen a través de RPC y los escribe en una base de datos local. El Remitente confirma que el gas se ha pagado por adelantado, recupera metadatos, simula y transmite la llamada del proceso. Si la entrega falla, el relayer reintenta automáticamente con una estrategia de retroceso exponencial. Las firmas de los validadores son de acceso público; cualquiera puede llevarlas y llamar al proceso. El remitente del mensaje selecciona el receptor prepagado a través del IGP, y el operador del relayer debe reequilibrar los ingresos a la cuenta de la cadena de destino.
¿Cómo se completa la entrega durante la fase de entrega en la cadena de destino?
La fase de entrega en la cadena de destino se activa cuando el relayer llama a Mailbox.process(metadata, message). El Mailbox primero verifica si el messageId ya se ha entregado; si existe en la asignación delivered, se rechaza la repetición. Luego, el Mailbox consulta el ISM especificado por el contrato receptor (a través de recipientIsm() o configuración personalizada de la aplicación) y pasa el message y metadata a la función ISM.verify().
Después de que la verificación del ISM sea exitosa, el Mailbox llama a la función handle(origin, sender, body) del contrato receptor, pasando el cuerpo del mensaje y la información de origen a la lógica de la capa de aplicación. El contrato receptor debe implementar la función handle de la interfaz IMessageRecipient. Esta función ejecuta operaciones de negocio como votación de gobernanza entre cadenas, acuñación o liberación de activos, o actualizaciones de estado. Una vez que la entrega tiene éxito, el Mailbox marca el messageId como entregado y emite eventos Process y ProcessId.
Para aplicaciones de activos entre cadenas como Warp Route, la función handle activa la lógica de bloqueo, acuñación, quema o liberación de tokens. Para aplicaciones de gobernanza entre cadenas, la función handle registra pesos de votación o ejecuta propuestas. El gas de la fase de entrega lo paga el relayer en la cadena de destino, mientras que el remitente ya ha pagado por adelantado la tarifa correspondiente en la cadena de origen a través del IGP.
Figura 2. Secuencia de entrega en la cadena de destino: el proceso de Mailbox activa la verificación del ISM; tras la verificación, se llama a handle del receptor y se evita la repetición mediante la asignación de messageId.
¿Cómo verifica el ISM de la cadena de destino los mensajes entre cadenas?
El ISM (Módulo de Seguridad Intercadena) es un contrato inteligente en la cadena de destino que se encarga de verificar la autenticidad de los mensajes entre cadenas. Antes de la entrega, el Mailbox pasa el message y los metadata enviados por el relayer a ISM.verify(). La lógica de verificación varía según el tipo de ISM. El ISM predeterminado es el ISM multifirma, que requiere que un número configurado de validadores firme la raíz Merkle de la cadena de origen hasta alcanzar un umbral. Las aplicaciones también pueden implementar ISM personalizados o usar el ISM de Agregación para combinar varias rutas de verificación.
Para verificar la configuración del ISM, puedes consultar la dirección del ISM del contrato receptor, comprobar el umbral de validadores y los parámetros del tipo de ISM, y confirmar el estado de verificación y los metadatos de un mensaje específico en el Explorador.
| Tipo de ISM |
Método de verificación |
Caso de uso |
| ISM multifirma |
Los validadores firman la raíz Merkle para alcanzar el umbral |
Modelo de seguridad predeterminado, mensajes generales |
| ISM de agregación |
Todos los ISM deben verificar |
Apilamiento de seguridad multicapa |
| ISM con límite de velocidad |
Limita el volumen de mensajes o transferencias por unidad de tiempo |
Activos de alto valor entre cadenas |
| ISM de enrutamiento |
Especifica diferentes ISM según la cadena de origen |
Estrategias de seguridad diferenciadas multicadena |
| ISM personalizado |
La aplicación define su propia lógica de verificación |
Requisitos comerciales especiales |
En el ISM multifirma, el relayer recupera firmas de puntos de control del almacenamiento público de los validadores y las envía junto con la prueba Merkle. El Módulo de Seguridad Económica proporciona seguridad económica a través de EigenLayer AVS; el fraude del validador puede provocar slashing. Si la verificación es exitosa, el ISM devuelve true y el Mailbox ejecuta handle; si falla, la transacción del proceso se revierte y el relayer reintenta según una estrategia de retroceso.
¿Cuáles son los riesgos y limitaciones del paso de mensajes entre cadenas?
El paso de mensajes entre cadenas de Hyperlane implica riesgos estructurales a nivel de mecanismo, que deben analizarse desde la capa de mensajes, la capa de transporte y la capa económica. Los riesgos de la capa de mensajes incluyen: una configuración incorrecta de los ISM personalizados puede debilitar la fuerza de verificación; las vulnerabilidades en la lógica de la función handle del receptor podrían provocar actualizaciones de estado incorrectas. Los riesgos de la capa de transporte incluyen: retrasos o detenciones del relayer pueden dejar mensajes sin entregar durante mucho tiempo (IGP pagado por adelantado pero el relayer no ha enviado); las fluctuaciones del precio del gas en la cadena de destino pueden afectar la disposición del relayer a enviar; la inactividad del validador en un ISM multifirma con un umbral alto puede dificultar la vitalidad.
Los riesgos de la capa económica incluyen: el fraude del validador podría provocar slashing de HYPER; una configuración incorrecta de la tarifa del IGP puede provocar tarifas de entrega insuficientes. La entrega de mensajes no es instantánea; es necesario esperar la finalidad de la cadena de origen y el envío del relayer. La fiabilidad depende del pago anticipado del IGP y de la calidad operativa del relayer.
| Fuente de riesgo |
Manifestación típica |
Estrategia de mitigación |
| Configuración del ISM |
Umbral de verificación demasiado bajo o validadores no confiables |
Auditar parámetros del ISM, usar ISM de agregación |
| Retraso del relayer |
Mensaje atascado en estado pendiente |
Rastrear mediante el Explorador, asegurar tarifas IGP suficientes, tener un relayer de respaldo |
| Inactividad del validador |
No se alcanza el umbral de firma multifirma |
Validadores redundantes, monitorear publicación de puntos de control |
| Vulnerabilidad del contrato |
Explotación de la lógica de handle o ISM |
Auditoría, ISM con límite de velocidad, ISM pausable |
| Ataque de repetición |
Mismo messageId entregado repetidamente |
La asignación delivered de Mailbox lo rechaza automáticamente |
Antes de operar, verifica las direcciones on-chain de los contratos Mailbox, ISM y receptor, y distingue entre las configuraciones predeterminadas del protocolo y las configuraciones personalizadas de la aplicación. Para escenarios como el cruce de activos de Warp Route, presta atención también al contrato de enrutamiento y las relaciones de mapeo de tokens.
Resumen
Los mensajes entre cadenas de Hyperlane siguen un flujo repetible: envío → atestación → relevo → verificar → entregar. Mailbox.dispatch() de la cadena de origen codifica el mensaje y lo escribe en el árbol Merkle; los validadores firman el punto de control (en escenarios de ISM multifirma); el relayer recopila metadatos y llama a process en la cadena de destino; tras la verificación del ISM, el Mailbox llama a handle para completar la entrega. El messageId es único a nivel global y los mensajes entregados no se pueden repetir. El IGP paga por adelantado el gas de la cadena de destino, y el Explorador proporciona un seguimiento completo del ciclo de vida.
Preguntas frecuentes
¿Cuál es el flujo básico de los mensajes entre cadenas de Hyperlane?
El remitente en la cadena de origen llama a Mailbox.dispatch() para enviar el mensaje. El Mailbox lo escribe en el árbol Merkle y emite eventos. El relayer escucha los eventos, recopila los metadatos requeridos por el ISM y llama a Mailbox.process() en la cadena de destino. Tras la verificación del ISM, el Mailbox llama a la función handle del receptor para completar la entrega.
¿En qué cadenas ocurren el envío y la entrega?
El envío ocurre en el contrato Mailbox de la cadena de origen, activado por el contrato remitente. La entrega ocurre en el contrato Mailbox de la cadena de destino, activada por el relayer que llama a process, y tras la verificación del ISM, se llama a handle del receptor.
¿Cuál es la diferencia entre el relayer y el validador?
El validador firma el punto de control de la raíz Merkle de la cadena de origen, proporcionando atestación para módulos de seguridad como el ISM multifirma. El relayer se encarga de la capa de transporte fuera de cadena: indexa eventos de la cadena de origen, recopila metadatos y envía la llamada de process en la cadena de destino. Sus funciones son complementarias: el relayer es esencial para todas las entregas de mensajes, mientras que el validador solo es necesario para tipos específicos de ISM.
¿Cómo puedo rastrear el estado de un mensaje entre cadenas?
Cada mensaje tiene un messageId único (el hash keccak256 devuelto en el envío). El Explorador de Hyperlane te permite consultar el estado del ciclo de vida completo del mensaje, desde el envío hasta el proceso, incluida la hora de envío en la cadena de origen, los registros de envío del relayer, los resultados de verificación del ISM y la confirmación de entrega en la cadena de destino.
¿Qué podría provocar que un mensaje no se entregue?
Las razones más comunes son: tarifas IGP pagadas por adelantado insuficientes, el relayer aún no ha enviado o está reintentando, las firmas de los validadores no han alcanzado el umbral multifirma, las tarifas de gas de la cadena de destino son demasiado altas lo que retrasa al relayer, o un fallo en la verificación del ISM. Puedes usar el Explorador para ver el motivo específico del estado pendiente y los registros de reintento de un mensaje en concreto.
¿Se puede entregar un mensaje entre cadenas dos veces?
No. El Mailbox mantiene una asignación delivered(messageId). Una vez que un messageId ha sido entregado, se rechaza durante el proceso en la cadena de destino, lo que evita ataques de repetición. El campo nonce también garantiza que, incluso si el cuerpo del mensaje es el mismo, diferentes envíos generen diferentes messageId.
