Por qué los puentes cross-chain son tan vulnerables a los hackeos

Diciembre de 2021 — Log4j es una biblioteca de registro de eventos ampliamente utilizada por un porcentaje increíblemente alto del código Java en todo el mundo. Este fallo no residía en un sistema operativo ni en una aplicación importante. Era una utilidad de la que la mayoría de los usuarios nunca había oído hablar y que vivía en las entrañas de sistemas que fueron auditados, mantenidos y defendidos durante muchos años. A las pocas horas de hacerse pública, ¡los escáneres de vulnerabilidades ya estaban rastreando cada servidor accesible en Internet para encontrarla! Hicieron falta meses para que el parche se propagara por completo.

No es una historia sobre blockchain. Pero es la mejor lente para comprender por qué los puentes cross-chain continúan siendo hackeados. Las cadenas de bloques individuales —Bitcoin, Ethereum, Solana— se diseñaron con un cuidado extraordinario en sus mecanismos de consenso, sus axiomas criptográficos y sus estructuras de incentivos para validadores. Sus protocolos subyacentes han pasado por años de investigación y pruebas frente a adversarios. Forjaron sus vínculos por separado, bajo distintas y estrictas limitaciones y de la mano de diferentes equipos, rara vez sometidos a un escrutinio exhaustivo. Y todo ese dinero está ligado a estas conexiones.

Qué es un puente y brevemente por qué es necesario

Las blockchains no se comunican entre sí de forma nativa. Bitcoin no tiene forma alguna de saber qué ocurre en Ethereum. Lo mismo sucede con los contratos inteligentes de Ethereum, que son ciegos al estado de Solana. Una vez más, por diseño, cada red está aislada: un sistema cerrado asegurado por la propia naturaleza de su aislamiento. Los validadores de esa cadena solo aceptarán lo que esté en consonancia con sus reglas, sin ningún dato proporcionado externamente que no puedan verificar.

En la práctica, esto se convierte en un problema a medida que el ecosistema crece. Si deseas utilizar las DeFi basadas en Ethereum pero solo tienes Bitcoin, actualmente no existe una vía directa. Esto obligaría a vender el Bitcoin, comprar Ethereum en un exchange centralizado y avanzar a partir de ahí; pero eso reintroduce exactamente el tipo de intermediario custodio que las finanzas descentralizadas supuestamente deben eliminar. Los puentes surgieron para cerrar la brecha entre cadenas a medida que la necesidad de una ruta descentralizada se volvió innegable.

El modelo lock-and-mint (bloquear y acuñar) es la arquitectura de puente más utilizada. Un usuario deposita tokens en la cadena A y los bloquea en un contrato inteligente. Este depósito es supervisado y certificado por un cuórum de validadores o un comité multisig. Esto genera una cantidad equivalente de tokens envueltos (wrapped tokens) en la cadena B: un activo sintético respaldado por la promesa de que el colateral existe para respaldar su valor en el otro extremo. Para la salida: el usuario quema los tokens envueltos en la cadena B, los validadores registran este evento y los activos bloqueados se liberan en la cadena A.

La elegancia de este modelo es también su problema. Estos activos bloqueados se custodian en un único contrato. No se mueven. Se acumulan. El puente es una cámara acorazada.

Las sidechains y su implementación en contratos cross-chain se formalizaron inicialmente en un artículo de 2014. Los atomic swaps —protocolos criptográficos para el intercambio de activos entre pares (P2P) y sin intermediarios de confianza entre cadenas— se introdujeron por primera vez en 2018. Ambos métodos pioneros presentaban desde entonces gravísimos problemas de escalabilidad. Debido a los mecanismos de consenso utilizados, los atomic swaps son bilaterales y requieren emparejar compradores y vendedores antes de que ocurra cualquier intercambio; no pueden funcionar como una infraestructura de liquidez generalizada. El puente lock-and-mint resolvió la escalabilidad incorporando un fondo de colateral bloqueado contra el cual cualquiera podía operar y, en consecuencia, generó básicamente un honeypot.

Los puentes prácticos comenzaron a existir entre 2020 y 2022, cuando el auge de las DeFi generó una demanda real de movimiento de capital entre cadenas. Esta generación estuvo personificada por Ronin Bridge, diseñado para el ecosistema de juegos de Axie Infinity. Wormhole, que conectaba Solana y Ethereum, y el Harmony Horizon Bridge, que unía la blockchain de Harmony con Ethereum, también contaron con este esquema. Cada uno de ellos empleaba pequeños comités de validadores para firmar las confirmaciones de las transferencias cross-chain: grupos compuestos habitualmente por entre cinco y doce firmantes (conocidos como comité) cuya firma colectiva servía para autorizar cualquier retirada. Era económico de operar y rápido en sus respuestas. También era un punto único de fallo que los atacantes podían calcular matemáticamente —

Cuatro hackeos, cuatro fallos distintos con una arquitectura común

En 2022, se produjo una oleada de ataques contra puentes que causó pérdidas acumuladas superiores a los 2.000 millones de dólares. Cuatro de ellos, no obstante, destacan sobre el resto, no porque fueran técnicamente idénticos —no lo eran—, sino porque cada uno ilustra una forma diferente en la que falla la misma arquitectura.

El mayor exploit de DeFi de la historia. En un momento que acabaría siendo el exploit individual de DeFi más cuantioso de todos los tiempos, Ronin Bridge fue hackeado por 624 millones de dólares el 23 de marzo de 2022. Para autorizar una retirada, el conjunto de validadores de Ronin dependía de un esquema de firmas de cinco sobre nueve. Solo en marzo, cuatro claves pertenecientes a Sky Mavis —los desarrolladores de Axie Infinity— se vieron comprometidas tras un ataque de spear-phishing disfrazado de una falsa oferta de trabajo. Sin embargo, meses antes de este incidente, Sky Mavis les había concedido de manera informal la autoridad de firma temporal sobre una quinta clave para gestionar el volumen de transacciones, y esa delegación nunca fue revocada. Los asaltantes contaban con cinco firmas a su favor. En dos transacciones drenaron de la red 173.600 ETH y 25,5 millones de dólares en USDC. Hicieron falta seis días para detectar la brecha.

En febrero de 2022, Wormhole perdió 326 millones de dólares debido a un fallo completamente distinto, marcando el fin de una caída en picado que duró siete semanas. La vulnerabilidad de seguridad, relacionada con una función obsoleta en el contrato inteligente de Solana —código que debería haberse eliminado durante una actualización rutinaria pero no se hizo—, permitió a un atacante eludir la validación de firmas. El atacante emitió un certificado de depósito falso, acuñó 120.000 Ether envueltos sin respaldo alguno y retiró Ether real del lado de Ethereum. Se comprobó que el defecto derivaba de un código provisional que no se limpió por completo y que nadie detectó durante la auditoría.

Nomad colapsó en agosto de 2022 a través de un mecanismo aún más humillante. Durante una actualización rutinaria, un parámetro de validación crítico se restableció a cero, lo que provocó que el contrato tratara cualquier prueba de transferencia como válida. A raíz de esto, una vez que el fallo fue descubierto y publicado abiertamente, más de 300 direcciones distintas —no atacantes sofisticados, muchos eran simples oportunistas— se abalanzaron sobre el puente en un saqueo masivo bajo la ley del primero que llega, primero que se sirve. Se esfumaron 190 millones de dólares.

Todo lo que tuvieron que hacer los atacantes fue hacerse con dos de las claves de firma críticas para el funcionamiento del Horizon Bridge de Harmony: justo el umbral para comprometerlo. Nunca hubo una confirmación pública sobre cómo se obtuvieron esas claves. La lección aprendida fue que un umbral de firma de 2 sobre 5 para un puente con activos de nueve cifras —incluso uno bien programado— simplemente no es suficiente.

El patrón continuó en 2023. Multichain, el protocolo de enrutamiento cross-chain más destacado, sufrió una pérdida de 126 millones de dólares en julio de 2023; no se debió a líneas de código explotables, sino a que su CEO fue detenido en China y sus claves privadas en posesión personal se utilizaron para drenar los fondos del puente. Orbit Chain fue atacada cuando 7 de sus 10 claves multisig resultaron comprometidas, provocando una pérdida de 81 millones de dólares. La razón principal de que el exploit fuera catastrófico en lugar de un mero incidente grave radicó, en todos los casos, en que un único contrato con todos los activos bloqueados dependía únicamente de unas pocas claves de control.

Las blockchains fueron meditadas. Sus conexiones no

Ethereum pasó años preparándose para su transición a la prueba de participación (Proof of Stake). Matemáticos profesionales llevan más de una década analizando las primitivas criptográficas detrás de la firma de transacciones en Bitcoin. Preparar las principales blockchains para su despliegue a escala requirió una enorme atención académica y de ingeniería sobre sus estructuras de incentivos.

Los puentes no tuvieron semejante periodo de desarrollo. Surgieron de retos prácticos, armados a toda prisa y pensados principalmente para captar una demanda urgente en una época en la que las DeFi crecían más rápido de lo que nadie podía analizar; se añadieron como parches sobre blockchains que no estaban construidas para interoperar, sin contar con los recursos institucionales ni con la comunidad de investigación adversaria que auditaba meticulosamente los protocolos base. Así es como nacen los bugs y vulnerabilidades en cualquier sistema complejo: se añade algo sobre una infraestructura existente sin la calidad requerida para ese diseño, cuando debió haber sido una prioridad de diseño de primer orden. Los puentes nacieron desde el primer momento con un gran valor total bloqueado (TVL) —porque así es como funcionan—, lo que provocó que los atajos de ingeniería tuvieran consecuencias inmediatas.

En enero de 2022, semanas antes del primer gran exploit de puentes de ese año, Vitalik Buterin advirtió explícitamente sobre este riesgo estructural. Señaló que los puentes dan lugar a un riesgo sistémico, ya que un ataque del 51% podría, en principio, amenazar la totalidad de los activos bloqueados en múltiples cadenas. Aunque su preocupación exacta no radicaba en los ataques a las claves de los validadores que acabaron ocurriendo, sino en la idea más abstracta de que los sistemas cross-chain heredan y amplifican los riesgos de sus cadenas componentes, este principio se ha demostrado en la práctica.

Cada generación sucesiva de los puentes principales ha abordado diferentes problemas manteniendo la misma vulnerabilidad central, y estos factores ayudan a entender el motivo:

Pequeños comités multisig económicos, rápidos y un blanco trivial para el robo de claves y el phishing — Generación 1 (2020–2022)

Generación 2 → (2023–2024) Billeteras con conjuntos amplios de validadores que utilizan redes de verificadores con incentivos económicos para mitigar el riesgo de claves comprometidas y reducir la confianza en la honestidad de los operadores fuera de la cadena (off-chain).

Esta es la primera arquitectura que elimina por completo la confianza en operadores humanos: a través de pruebas de conocimiento cero (zero-knowledge proofs) que permiten verificar matemáticamente el estado cross-chain (en la Generación 3 – 2025–presente), pero introduce nuevas complejidades: coste de generación de pruebas, latencia y la corrección de los circuitos.

Ni siquiera la generación más segura de puentes ha solucionado el problema al 100%. Esto implica que las pruebas de conocimiento cero son tan buenas como los circuitos a partir de los cuales se crearon. Y los bugs en circuitos no son algo inaudito. Además, los incentivos económicos que atraen un gran TVL a los puentes también atraen a hackers con presupuestos proporcionalmente elevados.

Quizás el cambio arquitectónico más significativo radique en sustituir los intermediarios de confianza por la verificación matemática. A diferencia de los modelos previos, un puente ZK no plantea la pregunta "¿podemos confiar en los validadores?": genera una prueba criptográfica de que algo ocurrió en la cadena de origen para una transacción específica y envía esta evidencia a la cadena de destino para su verificación on-chain. Llegados a ese punto, comprometer a un grupo de personas equivaldría a romper la criptografía subyacente y no a saltarse una garantía de seguridad fáctica.

Chainlink emplea decenas de redes independientes para respaldar su Protocolo de Interoperabilidad Cross-Chain (CCIP), junto con una Red de Gestión de Riesgos adicional que detecta comportamientos anómalos. Ningún mensaje cross-chain puede ejecutarse sin el acuerdo de ambas cadenas. Ninguna de ellas puede autorizar unilateralmente una transferencia. Se trata de un enfoque de defensa en profundidad aplicado a la propia arquitectura del puente.

La tercera vertiente se centra en los puentes basados en intenciones (intent-based). En lugar de mantener una inmensa reserva de colateral bloqueado susceptible de ser drenada, emparejan a los usuarios con proveedores de liquidez profesionales —"solvers"— que ejecutan transferencias cross-chain utilizando su propio inventario. El usuario les paga y el puente en sí no cuenta con un colateral agrupado que actúe como honeypot. La superficie de ataque pasa de "desvalijar la cámara acorazada" a "defraudar a un único solver", lo que representa un botín infinitamente menor.

Un enfoque más robusto consistiría en establecer un marco de trabajo ampliado entre ambas cadenas —algo que vaya más allá de un simple puente y se acerque a una capa de seguridad compartida—, lo que añade solidez técnica pero exige el compromiso de los propios equipos de las cadenas, no solo de desarrolladores externos. Lo que más se aproxima hoy a este concepto en la práctica es el modelo de parachains de Polkadot, donde las cadenas de bloques se acoplan a una cadena de relevo común (relay chain) y heredan su seguridad. El problema es que solo funciona dentro del ecosistema de Polkadot. Unir Ethereum y Bitcoin de la misma manera requeriría modificaciones en el protocolo de Bitcoin que su comunidad se ha negado a implementar reiteradamente.

Todas estas soluciones son más fáciles de describir que de construir. Generar pruebas zk para estados cross-chain complejos es costoso y exige un conocimiento criptográfico de primer nivel. Para que las pruebas se generen de forma segura, los circuitos precisan de verificación formal; los bugs en circuitos ZK pertenecen a un plano diferente al de los bugs habituales de smart contracts: aunque menos frecuentes, con un potencial notablemente más destructivo. ¿Por qué? Porque un fallo en la cadena del probador desmorona toda la garantía matemática que constituía el propósito fundacional de este enfoque. Asimismo, el sistema necesita suficiente competencia entre solvers para garantizar precios justos y evitar que los usuarios lo manipulen. Por último, si una solución requiere cambios a nivel de protocolo en blockchains existentes, se enfrenta a la vía de implementación más lenta posible: consenso comunitario, especificación de cambios, desarrollo, pruebas y despliegue final en redes que custodian cientos de miles de millones de dólares.

Qué te ocurre a ti cuando hackean un puente

Las consecuencias prácticas para los usuarios en un exploit de puente pueden clasificarse del siguiente modo, y ninguna de ellas es abstracta.

La más patente es la pérdida total. Si un usuario tiene activos en pleno tránsito por el puente durante un exploit, la transacción quedará atascada para siempre o quizá nunca vuelva a ver sus fondos. Si el contrato o el gestor del puente se desactivaran (pausaran o destruyeran), los activos bloqueados en la cadena de origen pasarían a ser inaccesibles. El activo envuelto permanece on-chain, pero deja de representar valor alguno. Los tokens envueltos en la cadena de destino no valen nada si el colateral subyacente que los respaldaba ha sido sustraído (por ejemplo, robado).

La paralización de los puentes genera demoras que se traducen en pérdidas acumuladas mayores. Ese incidente, de hecho, no fue un caso aislado en 2023; cuando Multichain se vio comprometido a principios de año, el puente permaneció fuera de servicio durante días antes de que sus operadores confirmaran el alcance de la brecha. No se ofrecieron plazos ni soluciones para los usuarios con transacciones legítimas pendientes. Más allá del riesgo de corrupción de datos, en mercados volátiles, perder la capacidad de transferir fondos entre cadenas durante días acarrea costes de oportunidad considerables, incluso si el capital se recupera más adelante.

El precio del activo atacado experimenta volatilidad casi instantáneamente tras un exploit de puente. Por lo general, los activos robados se liquidan masivamente en exchanges descentralizados por atacantes que buscan blanquear los fondos. La primera hora tras un hackeo de gran magnitud a un puente es invariablemente uno de los periodos de mayor turbulencia para los tokens afectados. Esto implica que incluso aquellos usuarios que no hayan utilizado el puente en absoluto pueden sufrir pérdidas en sus carteras, ya que otras tenencias en distintas plataformas se devalúan ante la noticia del ataque.

Una inquietud menos común pero igualmente destacable es la exposición de la privacidad. Las transacciones cross-chain exigen la coexistencia de datos on-chain en múltiples redes al mismo tiempo, y con un análisis exhaustivo de los registros de eventos de los contratos del puente, cualquier analista puede vincular las direcciones de un usuario en distintas cadenas. La separación entre cadenas como medida informal de privacidad desaparece en el momento exacto en que se utiliza cualquier puente interoperable.

Un último punto indiscutible: las plataformas y protocolos tienen un largo historial de restar importancia a los incidentes de seguridad y ocultar los detalles de sus arquitecturas hasta que se ven obligados a revelarlos. Equipos de desarrollo de puentes han guardado silencio ante exploits ya detectados, han calificado pérdidas cuantiosas como "pausas de investigación" y han reanudado su actividad sin resolver en realidad las condiciones estructurales que los hacían propensos al ataque. En cierto caso, se optó por desoír las advertencias públicas sobre un umbral de firmas deficitario durante 83 días antes de que se perpetrara el ataque anticipado. A pesar de que vaciaron la totalidad del TVL del puente, el hackeo de Ronin pasó inadvertido durante seis días completos.

La presión pública es prácticamente el único freno ante estas prácticas. Son los usuarios, investigadores y periodistas formulando preguntas incómodas sobre el tamaño de los conjuntos de validadores, los procesos de gestión de claves, los umbrales de firma y las metodologías de actualización quienes empujan a los equipos de los puentes a tratar estos aspectos como prioridades esenciales y no como notas al pie. No todos los proyectos que atraen esa atención subsanarán sus carencias de inmediato. Sin embargo, aquellos conscientes de estar bajo observación resolverán sus problemas mucho más rápido que quienes creen actuar sin supervisión. Estas presiones no son eternas, pero en una infraestructura que maneja dinero real, cualquier factor que conduzca a mejorar la seguridad merece ser aprovechado.

Para los operadores en TRON que buscan precios transparentes y sin incertidumbres: Netts ofrece alquiler de Energy, actualizando de forma dinámica el precio de la Energy por franja horaria según el estado real de la red TRON. El contraste entre la tarifa reducida de TRON Energy durante la noche (se cobra un mínimo de 23 sun entre las 01:00 y las 11:00 UTC) y las tarifas máximas (se aplican 37 sun de 14:00 a medianoche) permite a un usuario informado recortar sustancialmente los costes en transferencias de USDT simplemente eligiendo y planificando el momento de la transacción, o alquilando previamente la energía en el horario más ventajoso: una optimización de costes básica sustentada únicamente en saber qué parámetros comprobar. Si buscas Energy económica sin suscripciones ni compromisos excesivos de volumen, Netts opera bajo el modelo No Subscription, con todas las comisiones ya contempladas en el precio final mostrado al usuario.