Por qué la mensajería cross-chain es más difícil de lo que parece
Mover un token de Ethereum a Solana, o de una app-chain de Cosmos a un rollup, parece una simple transferencia en la superficie. Por debajo, la cadena de destino tiene que aceptar la palabra de un sistema externo de que un depósito, una quema o una votación realmente han ocurrido. Esa palabra es un mensaje, y la forma en que se verifica es todo el modelo de seguridad del puente.
El enfoque ingenuo consiste en entregar el trabajo a una cartera multifirma. Un grupo de validadores conocidos firma el mensaje, y la cadena de destino lo acepta cuando aparece un umbral de firmas. Es rápido, flexible, y también es el patrón de diseño detrás de la mayoría de los mayores exploits de puentes en la historia de las criptomonedas. Cuando una multifirma es la raíz de confianza, el puente solo es tan seguro como el menor número de claves comprometidas que puede tolerar.
El enfoque más profundo consiste en hacer que la cadena de destino verifique directamente la cadena de origen, del mismo modo que una persona verifica un pasaporte leyendo el sello del país emisor en lugar de confiar en la palabra de un tercero. Eso es lo que hace un cliente ligero. También es caro, lento de lanzar y limitado a cadenas que pueden ejecutar la lógica de verificación de la otra. Las tres pilas de este artículo se sitúan en un espectro entre estos dos extremos, y las diferencias importan más de lo que sugieren las páginas de marketing.
Riesgos que todo usuario cross-chain debería aceptar primero
Antes de comparar funciones, el planteamiento honesto es que cada mensaje cross-chain conlleva un riesgo que las cadenas subyacentes no tienen. Un token puenteado desde Ethereum a otra red, en sentido estricto, ya no es el token de Ethereum. Es un pagaré envuelto o acuñado que la cadena de destino solo puede honrar si el modelo de seguridad del puente se mantiene. Los puentes han sido la mayor fuente individual de pérdidas cripto por categoría durante tres años consecutivos.
El historial es aleccionador. El puente Ronin perdió aproximadamente 625 millones de dólares en 2022 después de que se comprometieran cinco de las nueve claves de validadores. El puente Wormhole perdió unos 320 millones de dólares en 2022 cuando un atacante eludió la verificación de firmas en Solana. El puente Harmony Horizon perdió alrededor de 100 millones de dólares en 2022. El puente Nomad perdió cerca de 190 millones de dólares a principios de 2023. En total, los puentes cross-chain han representado más de dos mil millones de dólares en pérdidas documentadas, y esa cifra subestima el panorama porque algunos incidentes se absorben discretamente.
Para los usuarios, los riesgos prácticos se agrupan en unos pocos bloques. El riesgo de smart contract en la cadena de destino puede permitir que un atacante acuñe activos sin respaldo. La compromisión de validadores en el lado de origen puede permitir que un ladrón apruebe un depósito falso. Los problemas de repetición o de finalidad pueden permitir que un mensaje sea aceptado antes de que la cadena de origen se haya liquidado realmente. La captura de la gobernanza puede cambiar las reglas a posteriori. Nada de esto es teórico. Todo ha ocurrido, y por eso una comparación de modelos de confianza es más útil que una lista de funciones.
Cosmos IBC y el modelo de confianza de clientes ligeros
IBC, el protocolo Inter-Blockchain Communication, es lo más parecido que tiene el sector a un estándar cross-chain nativo en términos criptográficos. Fue especificado por la Interchain Foundation y se lanzó dentro del Cosmos SDK, y desde 2021 está activo transportando activos y mensajes reales entre app-chains independientes. ATOM, el token nativo de Cosmos Hub, desempeña un papel de coordinación en ese ecosistema, aunque muchas cadenas compatibles con IBC tienen poca o ninguna exposición directa a ATOM.
La idea que define a IBC es que la cadena de destino ejecuta un cliente ligero de la cadena de origen, y la cadena de origen ejecuta un cliente ligero de la cadena de destino. Un cliente ligero es una pequeña pieza de código que verifica encabezados de bloque de otra cadena usando solo las reglas de consenso de esa cadena. Cuando la cadena A quiere enviar un paquete a la cadena B, registra el compromiso del paquete en su propio árbol de Merkle, y luego la cadena B verifica ese compromiso comprobando el encabezado que envió la cadena A, firmado por el conjunto de validadores de A. No hay multisig externa, ni oracle, ni relayer de terceros con poder para falsificar un mensaje. La seguridad del bridge es la seguridad de las dos cadenas implicadas.
Este modelo tiene consecuencias reales. Una app-chain de Cosmos y otra app-chain de Cosmos que ejecuten consenso de estilo Tendermint pueden conectarse con unas pocas líneas de configuración y heredar garantías muy sólidas. Conectarse a una cadena con un algoritmo de consenso diferente, como Ethereum, requiere escribir un cliente ligero personalizado en Solidity y un relayer que pueda pagar gas en ambos lados. Ese trabajo se ha hecho para Ethereum, y las conexiones resultantes de estilo ICS-27 Neutron son utilizables, pero exigen bastante más esfuerzo que las otras arquitecturas de este artículo.
El alcance limitado es la contrapartida. IBC no protege mágicamente rollups y alt-L1s arbitrarias. Cada conexión es a medida, y cada cadena conectada pasa a formar parte de la superficie de confianza. Eso es una ventaja desde el punto de vista de la seguridad, porque mantiene local el modelo de confianza, y una limitación desde el punto de vista del ecosistema, porque no escala con tanta facilidad como un bus de mensajes con permisos.
Seguridad compartida y el enfoque de app-chain
La tesis de app-chain detrás de Cosmos es que las aplicaciones serias merecen su propia blockchain, con su propio conjunto de validadores y su propio token de comisiones. IBC es el tejido conectivo que hace viable esa tesis, porque permite que muchas cadenas soberanas interoperen sin renunciar a su soberanía. La seguridad replicada, y su sucesora, la seguridad interchain, permiten a app-chains más pequeñas alquilar el conjunto de validadores de Cosmos Hub, lo que mejora su seguridad mientras mantiene IBC como capa cross-chain. El resultado es un modelo en el que los supuestos de confianza para un mensaje cross-chain son explícitos, locales y auditables, pero el coste es la fragmentación entre muchas cadenas con distintos niveles de calidad de validadores.
LayerZero y la pila DVN configurable
LayerZero toma un camino de diseño diferente. En lugar de ejecutar clientes ligeros completos en cada cadena, ejecuta un Ultra Light Node, que es un endpoint minimalista que almacena encabezados de bloque solo cuando es necesario y, por lo demás, depende de un relayer off-chain más una pila separada de Decentralized Verifier Networks, llamadas DVNs, para certificar un mensaje. La cadena de destino acepta un mensaje cuando las DVNs configuradas coinciden en que la transacción de la cadena de origen es válida.
Es una arquitectura de confianza minimizada en el sentido de que ninguna parte individual controla la entrega de mensajes, pero también es configurable. La aplicación que despliega un endpoint de LayerZero puede elegir qué DVNs verifican sus mensajes. La configuración predeterminada usa un conjunto específico, pero un desarrollador puede sustituirlo por otra pila de DVN para cambiar el perfil de seguridad de un bridge concreto. Algunos equipos han lanzado con una sola DVN, lo que en la práctica se acerca más a una multisig, mientras que otros usan múltiples DVNs de operadores independientes.
Los críticos de LayerZero han argumentado que esta flexibilidad es en sí misma un riesgo. Si una aplicación se despliega con DVNs débiles para ahorrar costes o latencia, la seguridad de ese bridge es débil por diseño. El equipo de LayerZero ha respondido ampliando el mercado de DVN e impulsando configuraciones predeterminadas que usan verificadores independientes, y el rediseño V2 del protocolo se apoya con más fuerza en una composición explícita de DVN. Aun así, la responsabilidad de elegir la pila de verificadores recae en última instancia en el equipo de la aplicación, lo que significa que un usuario que opera a través de un bridge de LayerZero tiene que confiar tanto en el protocolo como en las decisiones que tomó ese equipo.
El alcance de LayerZero es amplio. Está activo en la mayoría de las principales cadenas EVM, en Solana y en varias redes no EVM, y lo han usado grandes aplicaciones, incluido Stargate, un enrutador de liquidez cross-chain, y varios emisores de stablecoins. Ese alcance es una ventaja real, pero viene con un modelo mental más complejo: la seguridad de un bridge concreto depende de las DVNs seleccionadas, del contrato de la aplicación que aplica la verificación y de la versión del endpoint on-chain en uso.
Cómo las DVNs cambian las cuentas de confianza
La forma más sencilla de pensar en una pila de DVN es como un esquema de firmas conectable. Cada DVN puede ser un sistema de pruebas zk, un verificador basado en restaking, un servicio de certificación centralizado o una multisig operada por un operador conocido. Apilar DVNs independientes con distintas raíces de confianza es una defensa razonable, porque un atacante tendría que comprometer más de un verificador a la vez. Apilar DVNs correlacionadas que comparten infraestructura o gobernanza se parece más a tener un único punto de fallo disfrazado de muchos. Los equipos de aplicaciones que lanzan con DVNs baratas y correlacionadas obtienen el marketing de la descentralización y el perfil de riesgo de una multisig.
Wormhole y la multisig de guardianes
Wormhole, desarrollado originalmente por Certus One y ahora gestionado por la Wormhole Foundation, es la tercera gran arquitectura. Conecta Ethereum, Solana, BNB Chain, Aptos, Sui y una larga lista de otras redes, y históricamente ha sido uno de los diseños de bridge con mayor TVL del sector. Su diseño también es el más fácil de describir, y el más controvertido desde el punto de vista de la seguridad.
Los mensajes en Wormhole son certificados por un conjunto con permisos de 19 guardianes, cada uno de los cuales ejecuta un nodo que observa la cadena de origen y firma los eventos observados. Cuando 13 de los 19 guardianes firman el mismo mensaje, este se acepta en la cadena de destino. Los guardianes son operadores conocidos procedentes de todo el sector, y el conjunto está controlado por gobernanza, lo que significa que la Wormhole DAO puede añadir o eliminar guardianes.
El modelo de confianza es una multisig con un umbral alto. Si 7 de los 19 guardianes coluden, o si las claves de 7 guardianes se ven comprometidas, el bridge queda totalmente comprometido. Eso es un punto de centralización importante, y el exploit de 2022 hizo concretas sus consecuencias. Un atacante encontró una forma de falsificar una comprobación de firma en el lado de Solana de Wormhole, lo que le permitió mintear 120.000 ETH envueltos que no estaban respaldados por depósitos en Ethereum. La pérdida fue de unos 320 millones de dólares en ese momento, y fue respaldada por Jump Crypto, que había sido operador guardián e intervino para recapitalizar el bridge.
Desde entonces, Wormhole ha añadido un firewall de guardianes, ha reforzado su lógica de verificación on-chain y ha impulsado revisiones de seguridad adicionales. Nada de eso cambia el supuesto de confianza subyacente, que es que una multisig con permisos y un umbral de 13 de 19 es la raíz de la seguridad cross-chain. Para los usuarios, la pregunta práctica es si el conjunto de guardianes está lo bastante descentralizado, si los incentivos de los guardianes se alinean con una operación honesta y si la aplicación en la cadena de destino aplica correctamente la ruta de verificación.
Por qué el ranking por TVL es engañoso
La TVL de Wormhole se ha usado a menudo como indicador indirecto de su seguridad, según la lógica implícita de que más dinero confiando en un bridge significa que el bridge es más fiable. El historial apunta en la dirección contraria. Los bridges con mayor TVL son los objetivos más atractivos, y la posición de Wormhole cerca de la cima de esa lista es la razón por la que sus exploits han sido tan grandes. Un usuario que mira los depósitos totales no está viendo el modelo de seguridad, solo el premio disponible para un atacante.
Cómo se comparan IBC, LayerZero y Wormhole en las dimensiones que importan
El modelo de confianza es la dimensión principal, y en ese eje IBC es el más seguro por diseño, porque cada cadena verifica a la otra mediante consenso. LayerZero ocupa el segundo lugar, porque la pila DVN puede configurarse para ser criptográficamente robusta, pero solo si la aplicación elige verificadores que realmente lo sean. Wormhole ocupa el tercer lugar, porque la raíz de confianza es una multisig de guardianes con permisos que ya ha sido comprometida una vez y que solo mejora al ritmo al que se descentraliza y rota el conjunto de guardianes.
El alcance y la conectividad favorecen a Wormhole y LayerZero. Ambos se lanzan en decenas de cadenas de serie, y un desarrollador puede desplegar una aplicación cross-chain en cualquiera de los dos sin escribir un cliente ligero personalizado. IBC, en cambio, requiere una configuración por conexión, y una conexión a una cadena con un consenso poco familiar es un proyecto de ingeniería serio. Para una aplicación que necesita tocar rápidamente todas las redes principales, eso es un coste real.
La experiencia de desarrollo está hoy más o menos equilibrada entre LayerZero y Wormhole, y cada uno ofrece un endpoint relativamente sencillo y rutas de despliegue bien probadas. Las herramientas de IBC han mejorado mucho, con bibliotecas como ibc-go y relayers Hermes, pero la huella on-chain en el lado de Ethereum es más pesada y las herramientas EVM están menos maduras que las alternativas.
La latencia y el coste son difíciles de generalizar. Las conexiones IBC entre cadenas Tendermint son rápidas y baratas porque el relayer simplemente envía encabezados existentes. La latencia de LayerZero depende de la configuración DVN y de la frecuencia con la que el Ultra Light Node necesita actualizar el estado. La latencia de Wormhole depende de la agregación de firmas de los guardianes. Para transferencias de tamaño minorista, las tres opciones son competitivas; para arbitraje cross-chain de alta frecuencia, las diferencias en finalidad y gas pueden importar.
La gobernanza y las rutas de actualización son una superficie de riesgo infravalorada. Las actualizaciones de IBC ocurren a nivel de protocolo y requieren coordinación entre cadenas conectadas. LayerZero se ha iterado activamente, con V2 remodelando el modelo de confianza hacia una composición de DVN más explícita. La gobernanza de Wormhole reside en la Wormhole Foundation y el conjunto de guardianes, y el incidente de 2022 impulsó una hoja de ruta de seguridad más visible. Ninguna de estas rutas de gobernanza es totalmente trustless, y un usuario debería saber quién puede cambiar las reglas.
Implicaciones prácticas para desarrolladores y usuarios de DeFi
Para los desarrolladores, la conclusión honesta es que elegir una pila cross-chain equivale a elegir una raíz de confianza, y esa decisión debería tomarse antes de escribir una sola línea de lógica de negocio. Una aplicación que necesite las garantías más sólidas posibles y esté dispuesta a vivir dentro de un entorno estilo Cosmos verá que IBC es difícil de superar. Una aplicación que necesite un alcance amplio y esté dispuesta a gestionar cuidadosamente la composición de DVN encontrará flexible a LayerZero. Una aplicación que priorice el tiempo de salida al mercado y se sienta cómoda con un conjunto de guardianes permisionado encontrará que Wormhole permite lanzar rápido, entendiendo que el modelo de confianza es el que la página de marketing suele omitir.
Para los usuarios de DeFi, la lista de comprobación práctica es breve. Averigua qué puente utiliza un token para moverse entre las cadenas que te interesan. Lee cómo verifica los mensajes ese puente. Si la respuesta es una multisig, pregunta cuántos firmantes se requieren, quiénes son y cómo se gobiernan. Si la respuesta es un cliente ligero, pregunta si la cadena de destino ejecuta realmente ese cliente y con qué frecuencia se actualiza. Si la respuesta es una pila de DVN, pregunta qué DVN forman parte de la pila y si son independientes. Un activo envuelto o puenteado es tan seguro como la parte más débil de esa respuesta, y el token puenteado rara vez tiene el mismo perfil de riesgo que el activo subyacente en su cadena de origen.
También conviene recordar que el riesgo cross-chain no es estático. El conjunto de guardianes de un puente hoy puede no ser el conjunto de guardianes mañana. La composición de DVN de una aplicación de LayerZero hoy puede reconfigurarse mañana. Los clientes ligeros de una conexión IBC hoy dependen de conjuntos de validadores que pueden cambiar mediante gobernanza. Las suposiciones de confianza son algo vivo, y una comparación honesta es la que lo dice claramente.
Cómo seguir el riesgo cross-chain de forma inteligente
La infraestructura cross-chain avanza rápido, y también lo hacen las noticias sobre su seguridad. Seguir manualmente auditorías de puentes, rotaciones de guardianes, cambios en DVN y divulgaciones de exploits es una batalla perdida. Zippfeed muestra titulares cross-chain con puntuación de sentimiento, bullish, neutral o bearish, y una valoración de importancia, para que puedas ver qué eventos de puentes realmente movieron los mercados y cuáles fueron ruido. Combina eso con el hábito de preguntarte, cada vez, en qué conjunto de validadores estás confiando para el mensaje, y estarás por delante de la mayoría de los usuarios minoristas que aún tratan los puentes como infraestructura rutinaria.
Crypto Rank News
