Las blockchains mantienen su propio estado y sus propias reglas. Un contrato de una red no lee, verifica ni ejecuta automáticamente una llamada de contrato en otra. La mensajería entre cadenas es el problema general de llevar información desde un entorno de origen hasta uno de destino en una forma que el destino pueda verificar y procesar. La interoperabilidad es la capacidad más amplia de sistemas diseñados de manera independiente para intercambiar información o coordinar acciones mediante interfaces y supuestos definidos.
La palabra «mensaje» se usa deliberadamente de forma amplia. Puede codificar una instrucción, un identificador, una carga útil, una referencia de prueba o una solicitud de actualización de estado. No es automáticamente una transferencia de activos, y que llegue a algún lugar no establece por sí solo que un contrato de destino deba aceptarlo o ejecutarlo. Este artículo no es una recomendación; ofrece vocabulario para comprender los componentes y los límites de estos sistemas.
Un mensaje es información con contexto de origen y destino
En la comunicación entre cadenas, un mensaje suele contener más que una cadena arbitraria de bytes. Una descripción conceptual útil incluye una cadena de origen, un remitente de origen, una cadena de destino, un destinatario de destino, una carga útil e identificadores o atributos necesarios para el protocolo. El destino necesita una forma de vincular los datos recibidos con el contexto de origen en el que el diseño pretende confiar.
El contenido del mensaje puede describir una acción sin mover un token. Una instrucción de gobernanza, una actualización del estado de una aplicación o un registro de un evento pueden representarse como mensajes. La aplicación de destino aún necesita sus propias reglas para interpretar la carga útil. Transportar datos y autorizar una acción de aplicación son cuestiones separadas.
Esta separación importa porque una capa de transporte genérica no puede deducir la lógica de negocio de una aplicación. Un mensaje puede ser auténtico según la regla de verificación del transporte y aun así ser rechazado por la aplicación de destino porque es antiguo, está mal formado, se dirigió incorrectamente o no coincide con el estado local de la aplicación. La mensajería entre cadenas es, por tanto, una interacción entre el diseño del transporte y el de la aplicación.
La mensajería y los puentes de activos se solapan, pero no son idénticos. Un puente de activos suele coordinar un evento de origen con una acción sobre un activo en el destino. Según su mecanismo, puede bloquear, quemar, liberar, emitir o registrar de otra manera representaciones de tokens. Para hacerlo, con frecuencia transporta información entre redes; en ese sentido, un puente puede contener un componente de mensajería.
Pero la mensajería entre cadenas es más amplia que un puente. Un protocolo de mensajes puede llevar datos arbitrarios sin crear ni liberar un activo. A la inversa, el significado económico de un puente depende de reglas específicas del activo: qué se bloquea o quema, qué se emite o libera, qué derechos tiene la representación y cómo se define el trayecto de vuelta. Esas reglas no las aporta un formato genérico de mensaje. Esa distinción evita dos errores opuestos: tratar cada mensaje como transferencia de valor y suponer que todo puente es solo una herramienta para mover tokens. Un protocolo de interoperabilidad puede ofrecer una interfaz común para mensajes, mientras que aplicaciones separadas definen la contabilidad de activos, la gobernanza u otros efectos propios de la aplicación.
La verificación explica por qué un destino acepta un mensaje
La verificación es el proceso mediante el cual el lado de destino decide si la evidencia sobre un evento de origen satisface su regla de aceptación. La evidencia puede comprobarse mediante varias familias amplias de diseño. Un sistema puede verificar una prueba criptográfica relacionada con el estado de la cadena de origen, basarse en atestaciones de un conjunto definido de actores, depender de un arreglo de operadores de confianza o autorizados, o combinar mecanismos y usar uno como respaldo.
Son clasificaciones abstractas, no calificaciones. Un diseño basado en pruebas sigue dependiendo de la corrección del verificador, de los supuestos sobre el estado de origen y de la implementación de la lógica de destino. Un diseño basado en atestaciones depende de sus reglas declaradas y de la conducta supuesta de quienes atestiguan. Un arreglo basado en operadores depende de la autoridad y los controles definidos en ese arreglo. Cada modelo hace explícitos sus supuestos en un lugar diferente.
La verificación también debe vincular el mensaje al contexto previsto. Identificadores de la cadena de origen, identidades de remitentes, destinatarios de destino, direcciones de contrato, identificadores de mensaje y codificación de la carga útil pueden servir para ello. Sin contexto suficiente, datos aceptados en un entorno podrían interpretarse mal en otro. Los detalles pertinentes pertenecen a las especificaciones del protocolo y de la aplicación, no a un símbolo de token ni a una etiqueta general.
Un retransmisor lleva o presenta información, pero no define toda la confianza
Un retransmisor es un componente o actor que observa, transporta, presenta o reenvía la información necesaria para que un mensaje se procese en otra red. Puede publicar una prueba, presentar una atestación, entregar una carga útil o pagar una transacción en el destino según las reglas del sistema. Su función operativa suele tratar de la disponibilidad: si un mensaje puede avanzar hacia su entrega.
La función del retransmisor debe distinguirse de la fuente de verificación. En algunos diseños, cualquier persona puede retransmitir una prueba verificable de forma independiente; la regla del destino determina la aceptación. En otros, los retransmisores también forman parte de la autoridad que atestigua eventos de origen. En otros casos son un servicio de entrega específico de la aplicación. La misma palabra puede describir responsabilidades diferentes.
Esta distinción resulta útil al leer un modelo de seguridad. Un modelo de seguridad indica qué supuestos deben cumplirse para que se den las propiedades previstas de seguridad y disponibilidad del protocolo. Puede incluir supuestos sobre las cadenas de origen y destino, verificación de pruebas, umbrales de firmantes, disponibilidad de retransmisores, autoridad administrativa, mecanismos de actualización y manejo de tarifas. Ninguna etiqueta aislada de componente sustituye al modelo completo.
La finalidad delimita cuándo un evento de origen se considera liquidado
La finalidad es la regla o condición mediante la cual un sistema trata un evento de origen como suficientemente liquidado para una acción posterior. Las blockchains pueden tener modelos y tiempos de finalidad distintos. Un diseño entre cadenas debe especificar, de forma expresa o implícita, qué evidencia de origen acepta y cuándo la considera adecuada para procesarla en el destino.
Esto crea una frontera entre observación y aceptación. Ver un evento en una cadena de origen no equivale necesariamente a tratarlo como final para una acción de destino. Un diseño puede esperar una confirmación, prueba o condición de atestación concretas. El recorrido entre el evento de origen y la ejecución de destino puede tener así etapas, cada una con condiciones propias.
La finalidad tampoco implica que la acción de la aplicación de destino vaya a tener éxito. Una llamada de destino puede fallar por el estado local de la aplicación, límites de ejecución, una carga útil inválida o reglas que cambiaron entre la observación de origen y la presentación en destino. Una descripción completa separa finalidad de origen, verificación del mensaje, intento de entrega y ejecución de la aplicación.
La repetición y el orden son asuntos de la aplicación y del transporte
Una repetición ocurre cuando un mensaje antes válido se presenta o procesa de nuevo en un contexto en el que no se pretende una ejecución repetida. Los diseños de protocolo suelen vincular los mensajes a identificadores y contexto, y las aplicaciones pueden registrar si un identificador o nonce ya se consumió. El principio general de seguridad es la frescura: datos que fueron válidos una vez no deben seguir siendo automáticamente válidos para cada ejecución futura.
Los sistemas entre cadenas también deben tener en cuenta el orden. Mensajes observados en una cadena de origen pueden alcanzar el destino en momentos distintos por condiciones de red, reglas de finalidad, conducta del retransmisor y ejecución de destino. Un destino puede recibir un mensaje posterior antes que uno anterior, o observar una secuencia incompleta. Que el orden sea necesario, cómo se gestionen duplicados y qué suceda tras una llamada fallida son decisiones específicas de la aplicación.
Ni un identificador de mensaje ni la etiqueta de un retransmisor garantizan una secuencia correcta. Una aplicación que exige cambios de estado ordenados necesita reglas que hagan explícito el orden requerido. Una aplicación que tolera acciones independientes puede adoptar otro diseño. El orden, el reintento, la caducidad y la idempotencia forman parte del contrato del mensaje, no son detalles incidentales.
La interoperabilidad es una interfaz más un conjunto de supuestos
Un protocolo de interoperabilidad puede estandarizar cómo un remitente expresa un destino, una carga útil y atributos. Eso reduce la necesidad de que cada aplicación invente una forma nueva de mensaje. No borra las diferencias subyacentes entre cadenas ni hace equivalentes a todos los transportes. Redes distintas pueden usar formatos de dirección, reglas de ejecución, condiciones de finalidad y supuestos de seguridad distintos.
Por esta razón, la interoperabilidad tiene dos capas. La capa de interfaz describe cómo se comunican los componentes. La capa de garantía describe por qué un destino acepta un mensaje y bajo qué condiciones de fallo se comporta como se espera. Una interfaz compatible puede mejorar la portabilidad sin ocultar los supuestos de verificación y operación.
El término modelo de seguridad pertenece principalmente a la capa de garantía. Pregunta qué debe ser cierto para que un mensaje no autorizado no sea aceptado, uno autorizado no se procese más de lo previsto y uno válido tenga una vía hacia la entrega. Incluye dependencias como actualizaciones, gestión de claves y autorización de la aplicación. Esas preguntas no pueden responderse solo con el nombre de un protocolo.
Límites, categorías de fallo y descripciones cuidadosas
La comunicación entre cadenas introduce límites que no existen dentro de una sola cadena: observación de origen, evaluación de finalidad, verificación de mensajes, retransmisión, ejecución de destino e interpretación de la aplicación. Un fallo o demora en cualquiera de ellos puede afectar el resultado general. Un mensaje puede ser válido pero no entregarse; entregarse pero no ejecutarse; o ejecutarse en un contexto distinto de la secuencia prevista. Son categorías para analizar diseños, no afirmaciones sobre un servicio particular.
El lenguaje cuidadoso mantiene las categorías separadas. «Mensaje» describe información y contexto. «Verificación» describe la regla de aceptación. «Retransmisor» describe una función de entrega o presentación. «Finalidad» describe un umbral de liquidación. «Interoperabilidad» describe la capacidad de conectar sistemas mediante interfaces. «Modelo de seguridad» describe los supuestos y límites de fallo que dan significado a las propiedades previstas de un protocolo.
Ese vocabulario permite hablar de mensajería entre cadenas sin asumir que los activos se mueven, que los mensajes están ordenados o que una etiqueta prueba una propiedad de seguridad. No es una recomendación de seleccionar o interactuar con protocolo alguno; es un marco educativo para leer especificaciones y distinguir una interfaz de los supuestos que la respaldan.
Lecturas relacionadas
Otros artículos de Bitbase sobre este tema:
- Diseños de puente: bloqueo, quema y emisión nativa
- ¿Qué es Hyperlane? Interoperabilidad sin permisos
- ¿Qué es Particle Network? La abstracción de cadenas en la práctica
Aviso legal: Este artículo es contenido educativo de Bitbase Academy y se ofrece solo con fines informativos. No constituye asesoramiento de inversión, negociación, fiscal ni financiero. Los criptoactivos son volátiles; evalúa tu propio riesgo. Redactado en agosto de 2026; consulta la información oficial más reciente.
Fuentes
[1] ERC-7786: Cross-Chain Messaging Gateway eips.ethereum.org
[2] ERC-5164: Cross-Chain Execution eips.ethereum.org
[3] ERC-7964: Crosschain EIP-712 Signatures eips.ethereum.org
[4] NIST SP 800-63B-4: Authenticators pages.nist.gov
