Introducción
Las blockchains no se comunican entre sí. Ethereum no puede leer el estado de Solana. Arbitrum no puede verificar una transacción en Avalanche. Cada cadena mantiene su propio libro mayor, su propio consenso y sus propias reglas de finalidad. Este aislamiento es una característica del diseño de seguridad, pero crea un problema práctico: los usuarios tienen activos en una cadena y quieren usarlos en otra.
Los puentes existen para resolver esto. Un puente es un sistema que permite a un usuario depositar activos en la cadena A y recibir activos correspondientes en la cadena B. El concepto suena simple. La implementación es donde se han perdido miles de millones de dólares.
La dificultad central es la verificación. Cuando un usuario afirma haber depositado 100 ETH en Ethereum y pide 100 ETH en Arbitrum, alguien o algo debe verificar que el depósito realmente ocurrió. El mecanismo elegido para esta verificación determina el modelo de seguridad del puente, su velocidad, su costo y su superficie de ataque. Como señaló un análisis de Coinbase sobre los hacks de puentes, las fallas de seguridad de los puentes se derivan consistentemente de la brecha entre los supuestos de confianza que un puente afirma y los supuestos de confianza que realmente aplica.
Esta guía cubre cómo funcionan las principales arquitecturas de puentes, por qué cada uno de los mayores exploits tuvo éxito y qué verificar antes de confiar un puente con tus fondos.
Bloquear y acuñar: el mecanismo original de puente
El diseño de puente más antiguo y común es bloquear y acuñar. El mecanismo funciona en tres pasos:
- Bloquear. El usuario envía tokens a un contrato inteligente en la cadena de origen. Los tokens se bloquean (se mantienen) en ese contrato, no se queman ni se transfieren.
- Verificar. Un conjunto de validadores, relayeros o un oráculo observa el depósito en la cadena de origen y atestigua su validez en la cadena de destino.
- Acuñar. Un contrato inteligente en la cadena de destino acuña una versión sintética del token bloqueado. El usuario recibe "ETH envuelto" o "USDC puenteado" que representa un reclamo sobre el original bloqueado.
Para volver, el proceso se invierte: el usuario quema el token sintético en la cadena de destino, los validadores atestiguan la quema y los tokens originales se desbloquean en la cadena de origen.
La seguridad de bloquear y acuñar depende completamente del paso de verificación. Si un atacante puede convencer a la cadena de destino de que ocurrió un depósito cuando no ocurrió, puede acuñar tokens sin respaldo. Esto es exactamente lo que sucedió en los mayores exploits de puentes.
El problema aritmético. Los puentes de bloquear y acuñar deben mantener una proporción 1:1 entre los originales bloqueados y los sintéticos acuñados. Si se bloquean 10,000 ETH en Ethereum, exactamente 10,000 ETH puenteados deberían existir en la cadena de destino. Cualquier discrepancia significa que algunos tokens puenteados no tienen respaldo. Cuando los exploits crean sintéticos sin respaldo, los últimos usuarios en canjear encuentran la bóveda vacía. Esto crea una dinámica de pánico bancario: una vez que se difunde la noticia de un exploit, cada titular del token envuelto se apresura a canjear, sabiendo que solo los primeros en llegar recibirán activos reales.
Quemar y acuñar: tokens nativos entre cadenas
Quemar y acuñar elimina el problema del token envuelto al destruir el original y crear uno nuevo.
- Quemar. El token se destruye permanentemente en la cadena de origen.
- Verificar. El evento de quema se verifica en la cadena de destino.
- Acuñar. Se acuñan nuevos tokens de forma nativa en la cadena de destino.
Este modelo funciona solo para tokens cuyos emisores controlan la acuñación en múltiples cadenas. El Protocolo de Transferencia entre Cadenas (CCTP) de Circle para USDC es la implementación más grande. Cuando un usuario puentea USDC de Ethereum a Avalanche a través de CCTP, el USDC de Ethereum se quema y se acuña USDC nativo en Avalanche. No hay tokens envueltos, no hay fragmentación de liquidez y no hay sintéticos sin respaldo.
La limitación es que quemar y acuñar requiere que el emisor del token despliegue y opere infraestructura en cada cadena compatible. No es un mecanismo de propósito general. Los tokens ERC-20 arbitrarios no pueden usar quemar y acuñar a menos que sus desarrolladores construyan la infraestructura de acuñación entre cadenas. CCTP actualmente admite más de una docena de cadenas, pero cada integración requiere la participación directa de Circle.
Puentes de pool de liquidez: velocidad a través del capital
Un tercer modelo evita tanto el envolvimiento como la quema al usar pools de liquidez prefinanciados en cada cadena.
El mecanismo:
- Depósito. El usuario deposita tokens en un pool en la cadena de origen.
- Retiro. El usuario (o un relayer que actúe en su nombre) retira tokens equivalentes de un pool en la cadena de destino.
- Reequilibrio. El protocolo reequilibra periódicamente los pools entre cadenas para mantener una liquidez adecuada.
Stargate (construido sobre LayerZero) y Across Protocol utilizan variaciones de este modelo. La ventaja es la velocidad: como los tokens ya existen en la cadena de destino, no hay demora de acuñación. El usuario recibe tokens nativos reales de inmediato.
La desventaja es la eficiencia del capital. La liquidez debe estar preposicionada en cada cadena compatible, y ese capital solo genera rendimiento cuando los puentes se utilizan activamente. Durante períodos de bajo volumen, los proveedores de liquidez ganan poco mientras su capital permanece inactivo. Los requisitos de capital agregados en todas las cadenas compatibles pueden alcanzar cientos de millones de dólares, creando una barrera de entrada y un riesgo de concentración si un solo proveedor de liquidez domina.
El hackeo del puente Ronin: $624 millones por claves comprometidas
El 23 de marzo de 2022, los atacantes drenaron $624 millones en ETH y USDC del puente Ronin, que conectaba Ethereum con la sidechain de Ronin utilizada por el juego Axie Infinity.
El puente de Ronin utilizaba un esquema de validación multisig. Nueve nodos validadores verificaban las transacciones del puente, y cualquiera de los cinco podía autorizar un retiro. La suposición de seguridad era que comprometer cinco de los nueve validadores independientes sería poco práctico.
La suposición era incorrecta. Sky Mavis, la empresa detrás de Axie Infinity, controlaba cuatro de los nueve nodos validadores. Un quinto validador había otorgado a Sky Mavis permiso temporal para firmar en su nombre durante un período de alto volumen de transacciones y nunca revocó el permiso.
Los atacantes (atribuidos más tarde al Grupo Lazarus de Corea del Norte por el FBI) comprometieron los sistemas de Sky Mavis y obtuvieron las claves privadas de los cinco validadores. Con cinco de las nueve firmas, autorizaron dos retiros fraudulentos: 173,600 ETH y 25.5 millones de USDC.
La explotación no se descubrió durante seis días. Salió a la luz solo cuando un usuario intentó retirar 5,000 ETH y descubrió que el puente no tenía fondos suficientes.
La lección. La seguridad multisig es tan fuerte como la independencia de sus firmantes. Cuando una sola organización controla la mayoría de las claves, el multisig es un punto único de falla con pasos adicionales.
El hackeo de Wormhole: $326 millones por una evasión de verificación
El 2 de febrero de 2022, un atacante explotó el puente Wormhole para acuñar 120,000 wETH (ETH envuelto) en Solana sin depositar ningún ETH en Ethereum. La explotación valía aproximadamente $326 millones.
El puente de Wormhole dependía de un conjunto de 19 guardianes para verificar los mensajes entre cadenas. Los guardianes observaban un depósito en Ethereum, producían una atestación firmada (llamada VAA, Aprobación de Acción Verificada), y el contrato del lado de Solana verificaba las firmas antes de acuñar.
La vulnerabilidad estaba en la verificación de firmas del lado de Solana. El contrato de Solana de Wormhole utilizaba una instrucción de sistema obsoleta (verify_signatures) que no validaba correctamente las cuentas que se le pasaban. El atacante creó un conjunto de guardianes falso, envió un VAA falsificado con firmas de ese conjunto falso, y el contrato lo aceptó como válido.
En efecto, el atacante le dijo al contrato de Solana "estos guardianes aprobaron esta acuñación" y el contrato no verificó si los guardianes eran reales.
Jump Crypto, que respaldaba a Wormhole, reemplazó los 120,000 ETH robados de sus propias reservas. La restauración completa ocurrió dentro de las 24 horas, una respuesta sin precedentes que evitó pérdidas en cascada en los protocolos DeFi de Solana que tenían wETH.
La lección. El código de verificación del puente es una superficie de ataque de alto valor. Un solo error lógico en cómo se validan las firmas puede permitir una acuñación no autorizada ilimitada.
El hackeo de Nomad: 190 millones de dólares por una actualización defectuosa
El 1 de agosto de 2022, el puente Nomad fue drenado de aproximadamente 190 millones de dólares. A diferencia de Ronin y Wormhole, Nomad no fue atacado por un grupo sofisticado. Fue drenado por cientos de imitadores individuales después de que el exploit inicial se hiciera público.
Nomad utilizaba un modelo de verificación optimista. Los mensajes entre cadenas se enviaban y se asumían como válidos a menos que fueran impugnados dentro de una ventana de 30 minutos. Una actualización rutinaria del contrato introdujo un error: el contrato se inicializó con una raíz de confianza de 0x00, el valor cero de bytes32.
En la lógica de verificación de Nomad, cada mensaje se comprobaba contra la raíz de confianza. Debido a que 0x00 es el valor predeterminado para el almacenamiento no inicializado en Solidity, cada mensaje pasaba automáticamente la verificación. Cualquier usuario podía enviar cualquier mensaje y el contrato lo aceptaba como probado.
Una vez que el primer atacante demostró que se aceptaban mensajes arbitrarios, otros copiaron la transacción, cambiaron la dirección del destinatario y la reprodujeron. El puente fue drenado por un enjambre de atacantes oportunistas, incluidos hackers de sombrero blanco que luego devolvieron aproximadamente 36 millones de dólares en fondos recuperados.
La lección. Los errores de inicialización en los contratos de puente pueden ser catastróficos. Un solo parámetro mal configurado convirtió el modelo de seguridad de Nomad de "verificación optimista con pruebas de fraude" a "sin verificación en absoluto".
El hackeo de Harmony Horizon: 100 millones de dólares por una multisig de dos de cinco
En junio de 2022, el puente Harmony Horizon perdió 100 millones de dólares cuando los atacantes comprometieron las claves privadas de dos de los cinco validadores en la multisig del puente. El puente de Harmony requería solo dos de cinco firmantes para aprobar una transacción, un umbral inusualmente bajo para un puente que posee 100 millones de dólares.
El ataque reforzó la lección de Ronin: los puentes multisig son tan seguros como su conjunto de firmantes más débil. Cuando el umbral es bajo en relación con el número de firmantes, un solo compromiso de infraestructura puede ser suficiente. Los investigadores de seguridad habían criticado públicamente el umbral de dos de cinco de Harmony antes de que ocurriera el ataque.
La lección. La selección del umbral importa tanto como el número de validadores. Una multisig de cinco de nueve ofrece una seguridad significativamente diferente a una de dos de cinco, aunque ambas utilicen el mismo mecanismo subyacente.
Pérdidas acumuladas y patrones de ataque
La escala de las pérdidas en puentes no tiene precedentes en la seguridad de contratos inteligentes. Los exploits de puentes representan aproximadamente 3 mil millones de los 17 mil millones de dólares en hackeos cripto totales en la última década, lo que convierte a los puentes en la categoría de contratos inteligentes más atacada.
Los patrones de ataque se agrupan en tres categorías:
Compromiso de claves. El atacante obtiene suficientes claves de validador o firmante para falsificar mensajes del puente. Ronin y Harmony siguieron este patrón. La vulnerabilidad no está en el código sino en la seguridad operativa de la infraestructura de firmantes.
Bypass de verificación. El atacante encuentra un error en la lógica de verificación que permite que mensajes falsificados pasen. Wormhole siguió este patrón. La vulnerabilidad es un error a nivel de código en la función más crítica del contrato del puente.
Errores de inicialización o actualización. El atacante explota una mala configuración introducida durante el despliegue o la actualización. Nomad siguió este patrón. La vulnerabilidad es procedimental: el equipo cometió un error durante una operación rutinaria.
Cada patrón requiere una defensa diferente. El compromiso de claves se mitiga aumentando la diversidad de firmantes y utilizando módulos de seguridad de hardware. El bypass de verificación se mitiga mediante auditorías y verificación formal. Los errores de inicialización se mitigan con procedimientos de actualización que incluyan pruebas obligatorias en redes bifurcadas.
Un cuarto patrón emergente merece mención: ataques de gobernanza. Un atacante que acumula suficientes tokens de gobernanza para controlar el mecanismo de actualización de un puente puede modificar el contrato del puente para drenar fondos. Este ataque es más lento y más visible que los demás, pero apunta a puentes cuya gobernanza está concentrada o cuyo bloqueo de tiempo en las actualizaciones es demasiado corto. Los equipos de puentes utilizan cada vez más bloqueos de tiempo de varios días (48 a 72 horas) en las actualizaciones de contratos para dar a los usuarios tiempo para retirar fondos antes de que un cambio malicioso surta efecto.
La alternativa basada en intenciones a los puentes tradicionales
Un enfoque más nuevo evita por completo los contratos de puente mediante el uso de transferencias entre cadenas basadas en intenciones. El modo entre cadenas de Across Protocol y UniswapX permite a los usuarios expresar una intención de puente: "Tengo 1,000 USDC en Ethereum y quiero 1,000 USDC en Arbitrum." Un solucionador (llamado relayer) envía inmediatamente tokens desde su propio inventario en la cadena de destino, y luego reclama el reembolso más tarde.
Este modelo reduce la superficie de confianza. El usuario nunca deposita tokens en un contrato de puente que mantenga fondos agrupados. El solucionador asume el riesgo de reembolso, y el contrato de liquidación garantiza que el usuario recibió la salida prometida. No hay un gran grupo de activos bloqueados que un atacante pueda atacar.
La desventaja es la dependencia del solucionador: si ningún solucionador está dispuesto a completar la intención a un precio aceptable, la transferencia no se ejecuta. Para rutas de alto tráfico (Ethereum a Arbitrum, Ethereum a Base), la competencia de solucionadores es fuerte. Para rutas de bajo volumen, los solucionadores pueden no estar activos.
Puentes de cliente ligero y verificación de conocimiento cero
Las explotaciones anteriores comparten una debilidad común: dependen de validadores externos o multisig para atestiguar que algo sucedió en otra cadena. Si esos atestiguadores se ven comprometidos, el puente falla.
Los puentes de cliente ligero adoptan un enfoque diferente. En lugar de confiar en un conjunto de validadores, la cadena de destino ejecuta un cliente ligero que verifica directamente el consenso de la cadena de origen.
Un puente de cliente ligero hacia Ethereum, por ejemplo, rastrearía el conjunto de validadores de Ethereum y verificaría los encabezados de bloque y las pruebas de estado en cadena. Cuando un usuario afirma haber depositado tokens en Ethereum, el contrato del puente verifica la prueba de Merkle contra el encabezado de bloque de Ethereum que ya ha validado.
Este enfoque minimiza la confianza: el puente confía en el consenso de la cadena de origen, no en un comité externo. Pero es costoso. Verificar el consenso de Ethereum en otra cadena requiere una computación significativa, lo que se traduce en altos costos de gas.
Las pruebas de conocimiento cero ofrecen una solución al problema de costos. En lugar de verificar cada firma de validador en cadena, una prueba ZK puede comprimir la verificación en una sola prueba sucinta. La cadena de destino verifica una prueba en lugar de cientos de firmas.
Proyectos como Succinct Labs, Polymer y Lagrange están construyendo puentes verificados por ZK. Estos aún están madurando, pero representan el modelo de seguridad más fuerte para la comunicación entre cadenas: confiar en las matemáticas, no en el comité. Las implementaciones tempranas muestran que los costos de verificación están disminuyendo a medida que los sistemas de prueba ZK se vuelven más eficientes, con algunos puentes ya operando en mainnet con tiempos de prueba inferiores a 30 segundos.
Lo que esto no cubre
Esta guía explica la mecánica de los puentes y las mayores explotaciones. No cubre:
- Estrategias de puente específicas de tokens o qué puente usar para un activo determinado
- Comparación detallada de agregadores de puentes (Li.Fi, Socket, Bungee)
- La economía del suministro de liquidez para los grupos de puentes
- Protocolos de mensajería entre cadenas más allá de su función de puente (LayerZero, Axelar, Chainlink CCIP como capas de mensajería generales)
Comprobaciones prácticas antes de usar un puente
Verifique el mecanismo de verificación. Los puentes multisig son el modelo más débil. Los puentes de cliente ligero y verificados por ZK son los más fuertes. Los puentes optimistas se encuentran en el medio. Sepa en qué está confiando.
Examine el conjunto de validadores o guardianes. Para puentes multisig, verifique cuántos firmantes existen, quién los opera y si son genuinamente independientes. Si la mayoría de los firmantes pertenecen a la misma organización o jurisdicción geográfica, el multisig proporciona una seguridad limitada.
Revise el historial de auditorías. Los contratos de puente son objetivos de alto valor. Busque múltiples auditorías independientes de firmas de buena reputación. Un puente que no ha sido auditado, o que ha sido auditado solo una vez, merece una precaución adicional. Preste atención al alcance de las auditorías: una auditoría del contrato de token no cubre la lógica de verificación.
Considere el valor total bloqueado frente al presupuesto de seguridad. Un puente que mantiene $500 millones con un multisig de cinco de nueve presenta un perfil de riesgo muy diferente al de un puente que mantiene $5 millones. Los atacantes apuntan a puentes donde el pago potencial justifica el esfuerzo. El atacante racional calcula si el costo de comprometer suficientes claves es menor que el valor que se puede extraer.
Pruebe primero con cantidades pequeñas. Antes de transferir un valor significativo, envíe una pequeña transacción de prueba. Verifique que la dirección receptora, el token y la cantidad sean correctos. Las transacciones de puente son típicamente irreversibles.
Prefiere puentes nativos para rollups. Para los rollups de L2 de Ethereum (Arbitrum, Optimism, Base), el puente canónico hereda la seguridad directamente del consenso de Ethereum. Los puentes de terceros pueden ser más rápidos pero introducen supuestos de confianza adicionales. Utilice puentes canónicos para transferencias grandes donde la seguridad importa más que la velocidad.
¿Qué es un puente entre cadenas?
Un puente entre cadenas es un sistema que transfiere activos o datos entre dos blockchains que no pueden comunicarse de forma nativa. El puente bloquea, quema o agrupa tokens en una cadena y emite tokens correspondientes en otra, utilizando un mecanismo de verificación para garantizar que la transferencia sea legítima.
¿Por qué los puentes han sido hackeados tan a menudo?
Los puentes son objetivos de alto valor porque mantienen grandes grupos de activos bloqueados. También introducen supuestos de confianza complejos en el límite entre dos modelos de seguridad diferentes. Una vulnerabilidad en el mecanismo de verificación (claves comprometidas, comprobaciones de firmas defectuosas, errores de inicialización) puede permitir que un atacante drene todo el grupo en una sola transacción.
¿Cuál es la diferencia entre bloquear y acuñar y quemar y acuñar?
Bloquear y acuñar mantiene el token original en la cadena de origen y acuña una versión sintética (envuelta) en la cadena de destino. Quemar y acuñar destruye el original y acuña un nuevo token nativo en el destino. Quemar y acuñar produce tokens nativos en lugar de sintéticos, pero requiere que el emisor del token controle la acuñación en ambas cadenas.
¿Son seguros los tokens envueltos?
Los tokens envueltos son tan seguros como el puente que los emitió. Si el puente es explotado y los activos de respaldo son drenados, los tokens envueltos quedan sin respaldo y pierden su paridad. Los usuarios que mantienen tokens envueltos asumen el riesgo de seguridad del puente, no solo el riesgo del activo subyacente.
¿Cuánto tiempo tarda el puente?
Varía según el mecanismo. Los puentes de grupo de liquidez y los puentes basados en intenciones (Across) pueden completarse en segundos. Los puentes de bloquear y acuñar con verificación multisig típicamente toman de 10 a 30 minutos. Los puentes optimistas con ventanas de prueba de fraude pueden tomar 7 días para retiros de rollups optimistas a Ethereum, aunque los puentes rápidos pueden adelantar la liquidez para reducir esto.
¿Qué es un puente de cliente ligero?
Un puente de cliente ligero verifica el consenso de la cadena de origen directamente en la cadena de destino, en lugar de depender de un conjunto de validadores externos. Comprueba los encabezados de bloque y las pruebas de estado, confiando en la seguridad de la propia cadena de origen. Esto minimiza más la confianza que la verificación multisig u optimista, pero cuesta más gas de operar.
¿Puedo perder dinero usando un puente?
Sí. Si el puente es explotado después de que hayas depositado pero antes de que hayas retirado, tus tokens bloqueados pueden ser robados. Si mantienes tokens envueltos y el puente es hackeado, tus tokens envueltos pueden volverse sin valor. Además, direcciones de destino incorrectas o tipos de tokens no compatibles pueden resultar en pérdida permanente.
¿Qué puente debería usar?
Ningún puente es el mejor para todas las situaciones. Para USDC, el CCTP de Circle es la opción más segura porque utiliza quemar y acuñar sin tokens envueltos. Para transferencias generales de ERC-20, compare los mecanismos de verificación de los puentes disponibles. Prefiera puentes con verificación de cliente ligero o ZK, múltiples auditorías independientes y un historial de operación segura. Los agregadores de puentes como Li.Fi pueden ayudar a comparar rutas.
*Descargo de responsabilidad: Este artículo es solo para fines informativos y no constituye asesoramiento financiero, de inversión o legal. La criptomoneda implica un riesgo significativo, y debe realizar su propia investigación antes de tomar cualquier decisión. La información es precisa a agosto de 2026.*
