Qué hace realmente un puente cripto y por qué tiene que retener tu dinero
Un puente cripto es una infraestructura que te permite mover un token de una blockchain a otra. Si tienes ETH en la mainnet de Ethereum pero quieres usarla en Solana para operar con un token que vive allí, no tienes que vender el ETH, retirar a un banco y volver a comprar en el otro lado. En su lugar, envías tu ETH a un puente y al otro extremo recibes una versión "envuelta" que representa tu depósito en la nueva cadena.
Para que esto funcione sin un intermediario de confianza, los puentes utilizan casi universalmente alguna variante del modelo lock-mint o burn-mint. Tu ETH original se bloquea en un contrato inteligente en la cadena de origen (o se quema, que funcionalmente es lo mismo: el suministro se destruye), y se acuña una cantidad equivalente de ETH "envuelto" (a menudo llamado WETH, o para variantes cross-chain como la de Wormhole, un ETH envuelto por Wormhole) en la cadena de destino. Para regresar, quemas el token envuelto y el contrato libera (o vuelve a acuñar) el original en la cadena de origen.
Este diseño es elegante, pero tiene una consecuencia estructural que las personas ajenas a las criptomonedas suelen pasar por alto: en cualquier momento dado, el puente se apoya sobre todos los tokens que los usuarios han depositado alguna vez. Un puente que ha procesado mil millones de dólares en volumen puede tener 300 millones de dólares en custodia en su pico. Esa custodia vive en un contrato inteligente, y ese único contrato es toda la superficie de ataque. Roba las claves, compromete a los validadores o encuentra un solo bug, y te llevas todo. Compáralo con un DEX (exchange descentralizado) normal como Uniswap, donde la liquidez se reparte entre miles de pools independientes y un atacante que drene un pool no compromete a los demás. Los puentes concentran el riesgo como casi nada más en cripto.
Por qué los puentes siguen siendo hackeados: las tres debilidades estructurales
Cuando lees sobre un exploit de un puente, y ha habido muchos, los análisis post-mortem suelen describir un bug concreto o una clave concreta comprometida. Pero debajo de todos ellos se esconde el mismo trío de debilidades estructurales. Son lo que hace que los puentes sean objetivos especialmente atractivos.
Los puentes custodian un valor enorme en un único contrato. El modelo lock-mint significa que el contrato del puente en la cadena de origen guarda los activos reales, y los tokens envueltos en la cadena de destino son reclamaciones contra ese pool. Si acuñas en la cadena B sin un bloqueo real en la cadena A, has creado tokens envueltos sin respaldo cuyo precio se desplomará en el momento en que los usuarios intenten canjearlos. Así que todo el modelo de seguridad del puente se desploma sobre ese único contrato, más la autoridad de acuñación en el otro lado. Un DEX de mil millones de dólares son, en términos del atacante, mil honeypots de un millón. Un puente de mil millones de dólares es un honeypot de mil millones.
Los contratos de los puentes son difíciles de actualizar una vez que custodian dinero real. Podrías pensar: "Pues simplemente parchea el bug". En teoría, sí. En la práctica, los contratos de los puentes son intencionadamente no actualizables, porque la razón de ser de un puente con confianza minimizada es que ninguna parte pueda cambiar las reglas después de que deposites. Si el desplegador conservara una clave de actualización, podría hacer un rug pull a los depositantes en una sola transacción. Por eso los contratos son inmutables, y los contratos inmutables no se pueden parchear cuando se descubre una vulnerabilidad. El bug que lanzaste en 2021 es el bug que se explota en 2024, porque no hay una parte central con autoridad para arreglarlo sin romper la confianza de los usuarios.
El conjunto de validadores que protege el puente es más pequeño y débil que el de las cadenas que conecta. Este es el punto más subestimado. La mainnet de Ethereum está protegida por cientos de miles de validadores. Solana tiene miles. Un puente típico puede estar protegido por un multisig 5 de 9 (un monedero que requiere que cinco de nueve firmantes preaprobados aprueben cualquier acción), o por un pequeño conjunto de validadores que puedes enumerar en la cadena. Los atacantes estudian estos conjuntos como los atracadores de bancos estudian los turnos de vigilancia. Si cinco de esas nueve claves están en manos del mismo equipo, o si las claves se guardan en un servidor caliente en algún sitio, o si los miembros del multisig ni siquiera se conocen, el puente ha centralizado de facto su modelo de seguridad en un puñado de personas, y las personas, como demostró Ronin, pueden ser víctimas de phishing.
Cómo se ataca en la práctica el modelo de bloqueo-acuñación
Una vez que entiendes el modelo de bloqueo-acuñación, los patrones de ataque empiezan a parecer variaciones sobre un mismo tema. El atacante no necesita romper la cadena subyacente. Necesita romper una de tres cosas: el contrato de la cadena de origen que custodia los depósitos, el contrato de la cadena de destino que acuña los tokens envueltos, o la infraestructura fuera de la cadena que firma los mensajes entre cadenas.
Errores de contrato inteligente en la lógica de bloqueo o acuñación. El caso clásico es Wormhole en febrero de 2022. Wormhole era un puente popular entre Ethereum y Solana que permitía a los usuarios depositar ETH en Ethereum y recibir ETH envuelto en Solana. El atacante encontró un error en el código del lado de Solana de Wormhole: una función que el puente usaba para verificar que realmente había ocurrido un depósito en Ethereum estaba usando una cuenta de "conjunto de firmas" desactualizada que el atacante pudo reemplazar por una falsa. Con una firma falsa en su lugar, el atacante convenció al contrato de Solana de acuñar 120.000 ETH envueltos —valorados en unos 320 millones de dólares en aquel momento— sin bloquear nunca ETH real en Ethereum. Cuando se disipó el polvo, los usuarios que tenían el token envuelto en Solana descubrieron que su "ETH" no tenía respaldo, y el equipo de Wormhole tuvo que inyectar capital de su tesorería para resarcir a los depositantes. El error estaba en el código, no en las claves, pero el efecto estructural fue idéntico.
Compromiso del conjunto de validadores. Si un atacante puede reunir suficientes claves o ranuras de firmantes que aprueban mensajes entre cadenas, no necesita ningún error. Simplemente firma un mensaje fraudulento y el puente libera los fondos diligentemente. El hackeo del puente Ronin en marzo de 2022 es el ejemplo canónico. Ronin era una sidechain de Ethereum construida para el juego play-to-earn Axie Infinity, y su puente estaba protegido por una multifirma 5-de-9. Cinco de esos nueve firmantes eran operados por el mismo equipo (Sky Mavis, el desarrollador de Axie). Los atacantes comprometieron cuatro firmantes de Sky Mavis más un quinto socio, y se llevaron alrededor de 625 millones de dólares en USDC y ETH. No rompieron ninguna primitiva criptográfica —simplemente tenían acceso a suficientes firmantes legítimos.
Condiciones de carrera y errores de reejecución en el modelo de quema-acuñación. En un modelo de quema-acuñación, donde los tokens se destruyen en una cadena y se reacuñan en otra, un atacante a veces puede engañar al puente para que procese la misma quema dos veces, o que procese una quema sin esperar realmente a la confirmación entre cadenas. El hackeo del puente Nomad en agosto de 2022 fue una versión de esto: una actualización de rutina del contrato marcó accidentalmente como válido cada mensaje, así que cualquiera podía llamar al puente y retirar fondos como si hubiera depositado. Unos 190 millones de dólares fueron drenados por imitadores oportunistas antes de que el puente fuera cerrado.
Hackeos de puentes famosos y lo que enseña cada uno
Leer los análisis post-mortem de hackeos de puentes famosos es una de las formas más rápidas de interiorizar el modelo de amenaza. Cada uno demuestra una debilidad diferente en el mismo diseño general.
Wormhole, febrero de 2022 — ~320 millones de dólares. Causa: un error de verificación de firmas en el lado de Solana que permitió al atacante acuñar ETH envuelto sin respaldo. Lección: incluso el código bien auditado puede tener fallos de lógica en cómo interpreta los mensajes entre cadenas. El hecho de que el puente funcionara perfectamente durante años no significaba que fuera seguro.
Ronin, marzo de 2022 — ~625 millones de dólares. Causa: compromiso de cinco de las nueve claves de la multifirma mediante ingeniería social e infraestructura de un socio comprometida. Lección: la descentralización de validadores sobre el papel no es lo mismo que la descentralización de validadores en la práctica. Sky Mavis controlaba la mayoría de los firmantes "simplemente por comodidad" y esa concentración fue lo que se explotó.
Harmony Horizon, junio de 2022 — ~100 millones de dólares. Causa: compromiso de una multifirma 2-de-5 que protegía el puente, mediante claves de monederos calientes comprometidas. Lección: las multifirmas con umbrales muy bajos y almacenamiento de claves en monederos calientes apenas son mejores que un único firmante.
Nomad, agosto de 2022 — ~190 millones de dólares. Causa: una actualización del contrato que permitió accidentalmente retiradas arbitrarias. Lección: los contratos de puente diseñados para ser actualizables también pueden actualizarse a un estado vulnerable. La inmutabilidad tiene sus dos caras.
Si sumas solo esos cuatro incidentes, obtienes más de 1.200 millones de dólares en pérdidas, en un solo año, por una sola categoría de protocolo. Como referencia, todas las demás categorías de hackeos cripto combinadas —DEX, protocolos de préstamos, monederos, particulares— no destruyen capital a ese ritmo en relación con el TVL (valor total bloqueado, el valor de los activos depositados en un protocolo).
¿Compromiso del conjunto de validadores o error de contrato inteligente: cuál es más común?
Los errores de contrato inteligente reciben más prensa porque se leen como rompecabezas. Una comprobación de cero omitida, una raíz de Merkle desactualizada, una protección de reentrada que no se activa —estas son las cosas que los auditores destacan, y son las cosas en las que los desarrolladores trabajan para corregir. El compromiso de validadores es más desordenado. Involucra humanos, procesos internos, infraestructura fuera de la cadena y, a veces, atacantes patrocinados por Estados. Pero si sumas las pérdidas en dólares, el compromiso de validadores ha sido históricamente la categoría más grande por un amplio margen.
Los robos de Ronin, Harmony y varios más pequeños fueron esencialmente exploits del tipo "quien controle a los firmantes controla el puente". Los atacantes no necesitaron encontrar un camino ingenioso en el código; necesitaban una clave. Eso significa que defenderse contra ellos requiere un conjunto de herramientas diferente al de defenderse contra errores de contrato inteligente: módulos de seguridad de hardware (dispositivos de hardware especializados diseñados para mantener las claves privadas sin conexión y resistentes a la manipulación) en lugar de monederos calientes, firmantes distribuidos geográficamente, criptografía de umbral (donde una clave privada se divide en muchas partes de modo que ningún dispositivo o persona tenga nunca la clave completa) en lugar de multifirmas estáticas, y monitorización continua de la actividad de los firmantes. Ninguna de estas medidas es puramente on-chain, razón por la cual muchos puentes con conciencia de seguridad han migrado hacia redes de oráculos descentralizadas (servicios que llevan datos del mundo real o entre cadenas on-chain usando muchos nodos independientes, como la red impulsada por LINK de Chainlink) y pools de validadores dedicados para distribuir la confianza de forma más amplia.
Protocolos de mensajería entre cadenas como LayerZero y CCIP (Cross-Chain Interoperability Protocol) de Chainlink son un intento de hacer esto menos doloroso. En lugar de que cada puente monte su propio conjunto de validadores, externalizan la verificación de mensajes a una red más grande y más probada en batalla —en el caso de CCIP, la red de oráculos de Chainlink, que está diseñada para requerir el compromiso de muchos operadores de nodos independientes para falsificar un mensaje. La contrapartida es que has cambiado una pequeña suposición de confianza específica del puente por una suposición de confianza mayor a nivel de red, y deberías entender cuáles son los modos de fallo de esa red antes de depender de ella.
Seguridad compartida y CCIP como dirección alternativa
La lectura honesta del problema de los puentes es que ningún diseño elimina la suposición de confianza —solo la desplaza. Un puente que usa un conjunto pequeño de validadores confía en esos validadores. Un puente que usa una red de oráculos confía en la red de oráculos. Un puente que usa clientes ligeros (programas en una cadena que verifican de forma independiente las cabeceras de bloque de otra cadena, eliminando la necesidad de relayers externos) confía en que la criptografía y la implementación sean correctas. Un puente que usa un bloqueo basado en hash (el usuario bloquea fondos en un hashlock en una cadena y revela un secreto para reclamarlos en la otra, la base de los protocolos de atomic swap) confía en que exista liquidez en el lado receptor.
La seguridad compartida es el intento más reciente de enhebrar esta aguja. La idea es que, en lugar de que cada puente mantenga su propio conjunto de validadores a medida, se reutilizan validadores de una red grande y descentralizada —o de las cadenas subyacentes— para la verificación entre cadenas. CCIP de Chainlink es el ejemplo más prominente en producción hoy: en lugar de operar un conjunto paralelo de firmantes, el puente se apoya en la infraestructura de oráculos existente de Chainlink más una Risk Management Network independiente como segunda capa de defensa. El argumento económico es que atacar CCIP requeriría comprometer tanto la red de oráculos como la red de gestión de riesgo, lo cual es más caro que atacar la multifirma de un único puente.
Esta es una mejora real, pero no es una panacea. CCIP hereda las suposiciones de confianza de la red de oráculos de Chainlink. Si esa red se ve comprometida, CCIP queda comprometido. Si emerge un nuevo modelo de seguridad compartida y el 80% de los puentes lo adoptan, ese modelo se convierte en un único punto de fallo para todo el ecosistema cross-chain. Hay una razón por la que los usuarios experimentados de DeFi todavía dividen las transferencias grandes entre múltiples rutas y no confían cantidades que cambian su vida a un solo puente.
Cómo evaluar un puente antes de usarlo
No existe un "puente seguro". Cualquiera que te diga lo contrario te está vendiendo algo. Pero hay puentes que son más o menos arriesgados, y algunas preguntas que cambian de forma significativa el riesgo que asumes. Trata esto como una lista de comprobación, no como una garantía.
¿Cómo se distribuye la custodia? Analiza el administrador y el conjunto de firmantes en la cadena. Una multifirma 2 de 5 es drásticamente más arriesgada que una configuración 12 de 20. Comprueba si los firmantes son entidades independientes o ramas del mismo equipo. Observa cómo se almacenan las claves: las billeteras calientes en un servidor en la nube son una señal de alerta; las billeteras hardware distribuidas en distintas ubicaciones geográficas son mejores.
¿Los contratos son actualizables y por parte de quién? La inmutabilidad tiene sus dos caras. Un contrato inmutable no se puede parchear, lo que significa que un error seguirá siéndolo para siempre. Un contrato actualizable se puede parchear, lo que significa que un titular de clave malintencionado o comprometido también puede cambiar las reglas. Lee la documentación para entender exactamente qué poderes de actualización existen y quién los ostenta.
¿Ha sido auditado y por quién? Una auditoría no es una garantía. Una sola auditoría de una firma de nivel medio no es lo mismo que múltiples auditorías de firmas de primer nivel además de un programa público de recompensas por errores. Busca los informes de auditoría, comprueba qué se encontró y observa cómo respondió el equipo a esos hallazgos.
¿Cuánto tiempo lleva en producción y qué volumen ha procesado? Un puente que ha movido 20 000 millones de dólares durante tres años y nunca ha sido explotado tiene cierto historial empírico. Un puente lanzado la semana pasada no tiene ningún historial, por muy bien que se haya comercializado.
¿Cuál es el peor escenario de fallo? Lee los análisis post mortem de incidentes pasados y reflexiona: si el puente sufriera un hack mañana, ¿cómo se resarciría a los usuarios? ¿Existe un fondo de seguros? ¿Tiene el protocolo una tesorería lo suficientemente grande para cubrir las pérdidas? Si la respuesta es "nada", deberías tratar tu depósito como 100 % en riesgo en el momento en que aterrice.
Cómo seguir los exploits de puentes de forma inteligente
Los exploits de puentes se mueven rápido: cuando un análisis post mortem aparece en un blog, el siguiente incidente ya se está gestando. Hacer un seguimiento de qué puentes se están auditando, cuáles se están lanzando, cuáles han tenido incidentes de seguridad recientes y cómo está evolucionando el espacio cross-chain es un trabajo a tiempo completo si lo haces manualmente. Zippfeed muestra titulares sobre puentes e interoperabilidad con puntuación de sentimiento (alcista, neutral o bajista) y una calificación de importancia, para que puedas detectar señales relevantes sin tener que leer cada hilo tú mismo. Así, cuando se lance un nuevo puente "auditado" o un nombre conocido aparezca en un aviso de seguridad, lo verás en contexto, no en el pánico del torrente de tuits posterior al hackeo.
