TL;DR

  • no mueve nada: bloquea el valor en una cadena y crea un derecho en la otra, con una capa de mensajería que certifica que ambos eventos se corresponden. Todo lo interesante, y todo lo peligroso, reside en quién verifica esa certificación.
  • todos los fallos canónicos comprometieron la capa de certificación, las claves o el código de verificación, más que el consenso de las cadenas: cinco claves en el caso de Ronin, dos de cinco en el de Harmony, una prueba falsificada en el de BNB Bridge, un error en la comprobación de firmas en el de Wormhole y una raíz que aceptaba cualquier cosa en el de Nomad. Se atacaron más de 1.8 mil millones de dólares a través del intermediario; las pérdidas efectivas, tras las congelaciones y recuperaciones, superaron los 1.2 mil millones.
  • porque es el único componente que debe ser barato, rápido y flexible, por lo que los diseñadores optaron repetidamente por comités reducidos y código complejo a medida en lugar de la costosa opción de heredar la seguridad de la cadena, y ambas opciones concentran el fallo. El «honeypot» garantiza entonces que se detecte la opción más débil.
  • dos familias cambian realmente la geometría: la verificación con confianza minimizada, los clientes ligeros y las pruebas de conocimiento cero —que hacen que mentir sea tan difícil como romper la cadena de origen—, y la liquidación basada en la intención, que reduce o elimina por completo el «honeypot» agrupado. Todo lo demás mejora las probabilidades sin cambiar la forma.
en una cuadra

Un puente entre cadenas es un sistema de interoperabilidad que transfiere valor o mensajes entre blockchains que no pueden comunicarse entre sí.

¿Cómo transfiere realmente un puente el valor entre cadenas?

Respuesta rápida

no mueve nada: bloquea el valor en una cadena y crea un derecho en la otra, con una capa de mensajería que certifica que ambos eventos se corresponden. Todo lo interesante, y todo lo peligroso, reside en quién verifica esa certificación.

Ningún token se desplaza jamás. En el diseño dominante de «bloqueo y acuñación», depositas activos en un contrato puente en la cadena de origen; un mensaje cruza a la cadena de destino; allí, un contrato acuña una representación envuelta para ti. A la vuelta, el token envuelto se quema y el original se libera del bloqueo. Existen variantes, como «burn-and-mint» para tokens nativos multicadena, y diseños de redes de liquidez en los que los fondos de ambos lados se intercambian en lugar de envolverse, pero la constante se mantiene: algún componente debe convencer a la cadena de destino de que realmente ha ocurrido algo en la cadena de origen.

Ese componente es la capa de verificación, y su espacio de diseño es una escala de confianza. En el extremo más débil, un único operador o un pequeño comité se limita a firmar mensajes que dicen «el depósito se ha realizado», y el contrato de destino da por válido cualquier mensaje firmado correctamente. En el punto medio, conjuntos de validadores más amplios, esquemas de umbral y diseños optimistas con ventanas de fraude elevan el coste de una mentira. En el extremo más seguro, la cadena de destino verifica directamente la cadena de origen: un cliente ligero comprueba en cadena las pruebas de consenso de la cadena de origen, o una prueba de conocimiento cero da fe del estado de la cadena de origen, por lo que mentir requiere romper la propia cadena de origen.

Ahora añadamos el «honeypot». Los contratos de bloqueo de un puente que funciona correctamente acumulan el mayor fondo estático de valor del ecosistema: en sus momentos álgidos, los puentes individuales albergaban miles de millones. Así pues, la estructura del problema es una caja fuerte cuyo contenido combinado eclipsa a cualquier protocolo individual, custodiada por un mecanismo elegido de un menú en el que las opciones más baratas son más débiles que cualquiera de las cadenas que conecta. La economía prácticamente dicta el calendario de ataques: ataca la capa de certificación, acuña o libera sin un depósito real, y el fondo paga.

Las capas de consenso de las cadenas casi nunca son el punto de fallo. En los desastres canónicos de los puentes, las cadenas de bloques validaron exactamente lo que exigían sus reglas, registrando honestamente lo que les mostraba el intermediario comprometido; la excepción operativa confirma la regla, ya que los validadores de BNB Smart Chain tuvieron que pausar deliberadamente la cadena para contener el daño.

Diagram of a cross-chain bridge showing assets locked on a source blockchain, a verification layer of committee keys or proof-checking code in the middle, and wrapped tokens minted on a destination blockchain
Figura 1. Puente «lock-and-mint»: la caja fuerte compartida y la capa de verificación entre dos cadenas.

¿Qué tienen en común los mayores ataques a puentes?

Respuesta rápida

todos los fallos canónicos comprometieron la capa de certificación, las claves o el código de verificación, más que el consenso de las cadenas: cinco claves en el caso de Ronin, dos de cinco en el de Harmony, una prueba falsificada en el de BNB Bridge, un error en la comprobación de firmas en el de Wormhole y una raíz que aceptaba cualquier cosa en el de Nomad. Se atacaron más de 1.8 mil millones de dólares a través del intermediario; las pérdidas efectivas, tras las congelaciones y recuperaciones, superaron los 1.2 mil millones.

Ronin, en marzo de 2022, con unos 624 millones de dólares, sigue siendo el caso más emblemático. El puente que daba servicio al ecosistema de Axie Infinity estaba protegido por nueve claves de validador, siendo suficientes cinco de ellas. Los atacantes, a quienes las autoridades estadounidenses atribuyeron posteriormente al Grupo Lazarus de Corea del Norte, obtuvieron cuatro claves a través de un operador comprometido y una quinta gracias a un acuerdo de pago de gas que nunca se había desactivado tras un favor concedido meses antes. Cinco firmas más tarde, el fondo había desaparecido, y nadie se dio cuenta hasta seis días después, cuando un usuario detectó que las retiradas fallaban. Las lecciones fueron triples: un comité de «5 de 9» custodiaba dos tercios de mil millones de dólares; la expansión operativa dejó activa una clave obsoleta; y la supervisión era tan escasa que un robo de nueve cifras pasó desapercibido durante casi una semana.

Wormhole, en febrero de 2022, con unos 326 millones de dólares, fue un error de verificación: al contrato del lado de Solana se le podía introducir una certificación falsificada porque una ruta de comprobación de firmas obsoleta seguía siendo invocable, lo que permitió al atacante acuñar 120 000 ETH envueltos sin necesidad de depósito alguno. El inversor que respaldaba el proyecto recapitalizó el agujero en cuestión de días, lo que salvó a los usuarios y sentó un precedente incómodo sobre cómo se subsanan este tipo de agujeros.

Nomad, agosto de 2022, unos 190 millones de dólares, es la farsa del género: una inicialización dejó un valor cero marcado como raíz de confianza, por lo que prácticamente cualquier mensaje reproducido con los campos de destinatario editados sería aceptado. Una vez que el primer atacante lo demostró, cientos de imitadores se limitaron a modificar los calldata, un saqueo colectivo de una caja fuerte cuya puerta no verificaba nada.

Harmony Horizon, junio de 2022, unos 100 millones de dólares: una firma múltiple 2 de 5, dos claves comprometidas, no hace falta añadir nada más. BNB Bridge, octubre de 2022: un fallo en la verificación de la prueba Merkle IAVL permitió una prueba falsificada de un depósito que nunca se produjo, y se acuñaron unos 570 millones de dólares en BNB a partir de ella. La respuesta distingue entre los intentos de robo y las pérdidas efectivas: los validadores pausaron de forma sincronizada la BNB Smart Chain durante unas cinco horas; la mayor parte del valor acuñado quedó congelado en la cadena y se gestionó posteriormente; y la BNB Chain cifró la cantidad no recuperada en más de 100 millones de dólares. La pausa salvó la mayor parte del dinero y dejó claro un segundo punto de forma gratuita: una cadena que puede ser detenida por validadores coordinados dice mucho sobre cuál es realmente su grado de descentralización.

Chainalysis cuantificó la época: aproximadamente 2 000 millones de dólares atacados a través de puentes en 2022, la mayor parte de la actividad de fondos robados de ese año, siendo los actores estatales los responsables de la mayor parte. El patrón en una frase: se mantuvo el consenso, los intermediarios cayeron y lo que se salvó se salvó gracias a las congelaciones, más que por los propios puentes.

Bar chart of the Ronin, BNB Bridge, Wormhole, Nomad and Harmony bridge attacks showing over 1.8 billion dollars attacked through compromised keys and broken proof verification, with realised losses above 1.2 billion after freezes
Figura 2. Los cinco fallos canónicos de los puentes y la capa que cada uno de ellos rompió. El valor del BNB Bridge es la cantidad acuñada; la mayor parte se congeló tras una pausa coordinada.

¿Por qué la capa de verificación es estructuralmente el eslabón más débil?

Respuesta rápida

porque es el único componente que debe ser barato, rápido y flexible, por lo que los diseñadores optaron repetidamente por comités reducidos y código complejo a medida en lugar de la costosa opción de heredar la seguridad de la cadena, y ambas opciones concentran el fallo. El «honeypot» garantiza entonces que se detecte la opción más débil.

Piensa en lo que se le pide a la capa de verificación: observar una cadena, convencer a otra, rápidamente, para activos arbitrarios, a través de diseños de consenso heterogéneos, de forma actualizable y a bajo coste. La verificación completa mediante cliente ligero, que ejecuta las reglas de consenso de una cadena dentro de otra, fue durante años computacionalmente costosa en cadena, especialmente en el caso de cadenas con grandes cargas de firmas. Por eso, el sector recurrió a los comités: un conjunto de validadores conocidos supervisa la cadena de origen y firma las certificaciones. Los comités son rápidos y económicos, pueden dar soporte a múltiples cadenas siempre que se implemente el esquema de verificación y firma, y están protegidos por su umbral de firma junto con su código de verificación y su diseño operativo; en los fallos canónicos, la restricción vinculante era simplemente el número de claves que un atacante tenía que reunir, lo que, según los datos históricos, oscila entre dos y cinco.

El comité hereda todos los fallos clásicos de la gestión de claves: claves en equipos conectados a Internet, ingeniería social dirigida a los operadores, acuerdos obsoletos que nunca se revocan, diversidad insuficiente de firmantes, de modo que una sola organización comprometida da lugar a múltiples claves. Se trata de los mismos modos de fallo que el artículo sobre custodia institucional de este clúster trata como problemas resueltos, y que los puentes lanzan al mercado repetidamente sin las soluciones correspondientes. Cuando la verificación se basa en código en lugar de claves, con contratos de comprobación de pruebas a medida, la complejidad es enorme, la superficie de ataque es novedosa y, como demostraron Wormhole y BNB Bridge, una sola vía pasada por alto equivale a todo el fondo común.

La gobernanza añade un punto único de fallo más discreto: la mayoría de los puentes son actualizables, por lo que quien controle las claves de actualización controla, de forma transitiva, todos los activos bloqueados. Un diseño de verificación impecable tras una multisig de administración 2 de 3 es un puente 2 de 3 disfrazado.

Y la dinámica del «honeypot» cierra el círculo. El valor se concentra en los puentes ganadores; los puentes ganadores se convierten en los objetivos estáticos de mayor valor en el mundo de las criptomonedas; los adversarios más capaces, incluidos los grupos patrocinados por Estados con paciencia y gran dominio de la ingeniería social, se movilizan en consecuencia. La explotación de un protocolo DeFi reporta beneficios equivalentes a su propio TVL; la explotación de un puente reporta beneficios equivalentes al de todos. El fondo común es el premio, y el fondo común es exactamente lo que requiere la arquitectura dominante.

Este es el sentido estructural del título del artículo: los puentes siguen siendo hackeados porque el diseño dominante concentra el máximo valor tras una verificación mínima, y cada parche incremental deja intacta esa geometría.

¿Solucionan realmente el problema los diseños más recientes?

Respuesta rápida

dos familias cambian realmente la geometría: la verificación con confianza minimizada, los clientes ligeros y las pruebas de conocimiento cero —que hacen que mentir sea tan difícil como romper la cadena de origen—, y la liquidación basada en la intención, que reduce o elimina por completo el «honeypot» agrupado. Todo lo demás mejora las probabilidades sin cambiar la forma.

La familia de la verificación aborda la parte de la «verificación mínima». Un puente de cliente ligero ejecuta la verificación del consenso de la cadena de origen dentro de un contrato de la cadena de destino, de modo que una certificación se comprueba con datos reales del consenso en lugar de con la palabra de un comité; el protocolo IBC que conecta las cadenas de la familia Cosmos es el ejemplo en producción más longevo. Las pruebas de conocimiento cero amplían la idea a cadenas en las que la verificación en cadena resultaba antes demasiado pesada: una prueba sucinta de que la cadena de origen ha finalizado un estado determinado puede verificarse a bajo coste. Estos diseños eliminan el comité, pero no eliminan el riesgo por completo: el contrato verificador puede contener errores, las claves de actualización y de gobernanza pueden anularlo, y la disponibilidad de los datos, los supuestos de finalidad y la vitalidad siguen siendo problemas de ingeniería sin resolver. Lo que cambian es el tipo de fallo necesario, que pasa de robar unas pocas claves a romper el código de verificación o la gobernanza, lo cual supone un listón realmente más alto, aunque no absoluto.

La familia de diseños basados en la intención aborda la vertiente del «valor máximo». En los diseños basados en la intención, un usuario expresa un resultado —el activo X en la cadena B— y los solucionadores competidores aportan su propia liquidez en el destino en cuestión de segundos, para luego liquidar la operación contra el depósito del usuario en la cadena de origen a través de la ruta de verificación del sistema. La exposición del usuario se reduce a una única ventana de ejecución, en lugar de una reclamación perpetua sobre un fondo común gigante; el solucionador, un profesional que asume un riesgo profesional, asume la exposición de la liquidación y la valora. Estándares como el ERC-7683 formalizan este patrón en todas las cadenas EVM. El diseño no elimina la verificación —la liquidación sigue necesitando veracidad— y las capas de liquidación aún pueden concentrar la exposición; lo que elimina, en diseños en los que los fondos de los usuarios nunca se agrupan realmente, es el «honeypot» inactivo que hizo posibles eventos aislados a la escala de Ronin. La exigencia de verificar cualquier sistema específico es precisamente eso: dónde se encuentra el valor, durante cuánto tiempo y detrás de qué.

El panorama general desde 2022 invita a un optimismo cauteloso: las pérdidas en los puentes han dejado de ocupar un lugar predominante en las estadísticas de robos, gracias a una combinación de comités reforzados, supervisión, migración arquitectónica y al hecho de que los atacantes han encontrado objetivos más vulnerables en el compromiso de claves operativas. Un optimismo con una salvedad que el historial de incidentes insiste en destacar: varios puentes de «próxima generación» de 2021 también se describían a sí mismos como soluciones que habían resuelto la seguridad de los puentes.

Para un usuario, todo esto se reduce a una serie de preguntas. ¿Qué verifica un cruce: un comité, una ventana optimista, un cliente ligero, una prueba? ¿Cuántas claves hay, quién las custodia, cómo está compuesto el comité y quién puede actualizar los contratos con qué plazo de demora? ¿El valor se agrupa en un fondo común y en qué medida, o lo aportan los solucionadores? ¿Cuánto tiempo lleva funcionando el diseño, con qué valor y tras qué auditorías? Y, siempre presente: ¿es realmente necesario que se produzca este cruce, o acaso la cadena nativa del activo, o una transferencia interna en una plataforma centralizada —con sus propios riesgos específicos—, supone una exposición total menor? El principio del pilar se aplica al pie de la letra: todo diseño reubica el riesgo en lugar de eliminarlo, y la habilidad consiste en saber adónde ha ido a parar el tuyo.

Preguntas frecuentes

¿Es seguro utilizar los puentes criptográficos?

La seguridad varía más en función de la arquitectura que de la marca. Un cruce verificado por un cliente ligero o una prueba de validez elimina el comité externo, aunque sigue conllevando riesgos relacionados con la implementación del verificador, las actualizaciones, la disponibilidad de datos y la vigencia; un cruce verificado por un comité reducido es tan seguro como un puñado de claves; una ejecución basada en la intención limita tu exposición a una ventana de liquidación. Comprueba qué verifica el cruce, quién puede actualizarlo y cuánto valor hay en el fondo común, y mantén cada cruce individual pequeño en relación con lo que te puedes permitir que quede bloqueado o se pierda.

Si ambas cadenas de bloques son seguras, ¿cómo se puede piratear el puente?

Porque el puente es un tercer sistema que se interpone entre ellas. Cada cadena ejecuta fielmente las instrucciones que se le muestran; la capa de verificación del puente es la que decide qué instrucciones se muestran. Si se compromete esa capa —cinco claves en Ronin, un error de prueba en BNB Bridge—, ambas cadenas registran fielmente el robo. La seguridad de las cadenas nunca estuvo en duda.

¿Cuál fue la causa principal más común en los grandes ataques a los puentes?

Una certificación comprometida o insuficiente: o bien un número insuficiente de claves (cinco de nueve en Ronin, dos de cinco en Harmony) o bien un código de verificación defectuoso que aceptaba mensajes que debería haber rechazado (Wormhole, Nomad, BNB Bridge). Más de 1.800 millones de dólares en los cinco casos más emblemáticos fueron objeto de ataques a través de esas dos vías, con pérdidas efectivas superiores a los 1.200 millones tras las congelaciones, mientras que las reglas de consenso de las cadenas funcionaron según lo previsto.

¿Los tokens envueltos conllevan riesgo de puente incluso después de recibirlos?

Sí. Un token envuelto es un derecho sobre activos bloqueados en el puente; si se vacía el bloqueo, el derecho puede perder su respaldo independientemente de cuándo hayas cruzado. Mantener activos envueltos de un puente supone una exposición crediticia continua a la seguridad de dicho puente, algo que conviene recordar cuando un saldo de tokens envueltos permanece inactivo durante meses.

¿Es más seguro transferir fondos a través de una plataforma de intercambio en lugar de un puente?

Se cambia un riesgo por otro: la custodia, la solvencia y la seguridad de las cuentas de una plataforma centralizada sustituyen a la capa de verificación del puente, y los artículos de esta academia sobre la seguridad de las cuentas en las plataformas de intercambio y la custodia institucional abordan ese aspecto. Para transferencias de gran volumen, algunos profesionales prefieren las vías de las plataformas precisamente para evitar la exposición conjunta al puente; lo más honesto es planteárselo como elegir a qué tipos de fallos estás preparado para hacer frente, ya que nunca hay nada gratis.

Fuentes y lecturas recomendadas

Referencias clave para este artículo, actualizadas a julio de 2026. Las cifras volátiles se vuelven a comprobar en cada revisión trimestral.

Prueba rápida: ¿se mantuvo?

Llegaron algunas preguntas para comprobar los fundamentos. Siguen respuestas con explicaciones y nadie lo califica excepto su futuro portafolio.

1/5 pregunta
¿Qué transfiere realmente un puente de «lock-and-mint» entre cadenas?

¿Fue esto útil?