Un puente no mueve nada. Formula una afirmación en una cadena y convence a una segunda cadena de actuar según ella, y cada puente reventado es esa segunda cadena creyendo una afirmación que debería haber rechazado. Por eso conviene ordenar el riesgo de los puentes por supuesto de confianza y no por nombre de producto: qué cree la cadena de destino y qué haría falta para que creyera algo falso. Este artículo recorre cinco fuentes estructurales, desde los conjuntos externos de validadores hasta las claves de actualización.
La pregunta que ordena cualquier puente
La propia documentación para desarrolladores de Ethereum comprime la seguridad de un puente en una sola pregunta: ¿quién verifica el sistema? Las comisiones, la velocidad y el número de cadenas conectadas quedan todas aguas abajo de ella.
La mecánica apenas varía. En la cadena de origen ocurre algo. Alguna parte atestigua que ocurrió. Un contrato en la cadena de destino coteja ese testimonio contra una regla y, si pasa, libera o emite. Todo lo que quiere un atacante está al otro lado de esa regla.
La documentación divide los diseños en dos familias. Los puentes de confianza se verifican desde fuera: una federación con multifirma, un sistema de computación multiparte o una red de oráculos. Los puentes sin confianza se apoyan en las cadenas que conectan y en los validadores de esas cadenas, sin añadir un supuesto nuevo. La primera familia compra conectividad y velocidad y lo paga en seguridad: un puente protegido por validadores externos suele ser más débil que uno protegido de forma nativa por las propias cadenas.
El dinero en juego vuelve implacable ese intercambio. Hasta agosto de 2022, Chainalysis contabilizó 13 ataques distintos a puentes entre cadenas por unos 2 mil millones de dólares, alrededor del 69 % de todo lo robado en cripto ese año hasta ese momento. Los puentes atraen ataques porque concentran las garantías justo en el punto donde se comprueba una única regla.
Por eso las secciones siguientes están ordenadas por supuestos y no por incidentes. Dos puentes con nombres distintos y el mismo modelo de verificación fallan igual, y saberse los nombres no dice nada sobre el que estás a punto de usar.
Un conjunto externo de validadores es un sistema que no auditaste
El diseño de confianza más común coloca un conjunto de N partes entre las dos cadenas. Vigilan la cadena de origen, firman un testimonio de que un evento ocurrió y el contrato de destino lo acepta si verifican al menos M de esas firmas. El contrato no tiene ninguna otra opinión sobre la realidad.
La consecuencia es directa: quien controle M claves puede emitir. Toma un conjunto de 9 con un umbral de 5. Un atacante con 5 claves no necesita un fallo en el contrato, ni una debilidad en ninguna de las dos cadenas, ni ninguna comprobación adicional. Mientras lo vacía, el puente hace exactamente aquello para lo que fue construido.
Fíjate en qué seguridad estás comprando de verdad. El conjunto de validadores es un sistema propio, con sus operadores, sus máquinas y sus incentivos, y no hereda nada de las cadenas que une. Un puente verificado por un conjunto externo es tan fuerte como ese conjunto y ni un poco más, por grandes que sean las redes a uno y otro lado.
Así que las preguntas que valen son preguntas sobre la composición. ¿Quiénes son esos N, y están siquiera publicados? ¿Son organizaciones distintas o una sola organización con nueve máquinas? ¿Cuánto vale M? ¿Tienen los miembros algo en juego que se les pueda quitar si firman un mensaje falso? ¿Y quién puede cambiar la composición, porque un conjunto que una sola clave puede reescribir es un puente de una firma disfrazado de comité?
Un umbral solo cuenta si las claves fallan de forma independiente
M-de-N es una afirmación sobre independencia, no una cuenta. Cinco de nueve es apreciablemente más difícil que uno de uno solo si esas nueve claves pueden fallar de nueve maneras no relacionadas.
A menudo no pueden. Las claves guardadas dentro de una misma empresa comparten un proceso de contratación, una imagen de portátil, una VPN, un servicio de claves en la nube y una única interfaz de firma. Si un solo mensaje de phishing alcanza a los nueve titulares, o si una cuenta en la nube guarda cinco de ellas, N es un número en un panel y el N real está más cerca de 1.
Subir el umbral no arregla esto, y algo cuesta. Con una M alta, perder unas pocas claves deja al puente sin poder firmar nada: no roban nada, pero tampoco se mueve nada, y quien tenga activos en el lado equivocado espera. Todo umbral es una elección entre demasiado fácil de robar y demasiado fácil de congelar.
La superficie de firma merece tanta atención como la custodia. Quienes firman aprueban datos que en su mayoría no pueden leer, así que si la interfaz muestra un resumen amable mientras los bytes de debajo dicen otra cosa, firmantes honestos producen una firma maliciosa válida. La firma a ciegas convierte un comité M-de-N en un sello de goma M-de-N, y ningún umbral protege de eso.
Los clientes ligeros y la verificación optimista apuestan a cosas distintas
Los diseños que minimizan la confianza eliminan el conjunto externo, pero no eliminan la confianza: la reubican. Dos familias hacen casi todo el trabajo.
La verificación con cliente ligero mete un cliente de la cadena de origen dentro de la cadena de destino. El destino guarda el estado de consenso del origen y comprueba si el evento alegado queda probado contra él. En IBC, cada lado de una conexión usa el cliente ligero de la otra cadena para verificar los mensajes entrantes, así que el supuesto se reduce al consenso de la cadena de origen más la corrección del código del cliente. La versión más reciente de IBC lo dice sin rodeos: un cliente es simplemente un modelo de verificación, y puede ser igualmente un cliente ligero, una multifirma o un verificador de pruebas. La etiqueta no es el supuesto; el tipo de cliente sí.
La verificación optimista hace lo contrario: acepta el mensaje de forma provisional y da a cualquiera una ventana para demostrar que es falso. El supuesto es que al menos un vigilante está en marcha, con fondos y en condiciones de meter una transacción de impugnación antes de que la ventana se cierre. Un vigilante apagado, sin gas o censurado durante la ventana equivale a no tener vigilante.
Ninguna de las dos familias es gratis, y los costes son estructurales, no accidentales. Los clientes ligeros cuestan gas e ingeniería por cada par de cadenas, y un fallo en el cliente es un fallo en la regla misma. Los diseños optimistas conectan barato, pero obligan a cada usuario honesto a esperar un retraso elegido por el diseñador. La documentación de Ethereum nombra ambos costes directamente: límites de conectividad en los puentes con cliente ligero y de velocidad en los optimistas.
La repetición es un mensaje válido contado dos veces
Un mensaje de puente es una autorización. La repetición es el ataque en el que una autorización realmente emitida se presenta otra vez: una segunda vez en el mismo sitio, o una primera vez donde nunca debió aplicarse. No se falsifica nada. Simplemente se reutilizan los mismos bytes válidos.
La solución canónica está en la propia historia de Ethereum. EIP-155 mete el chain ID dentro de los datos que se resumen y se firman, de modo que una firma hecha para una cadena no verifica en otra. Fíjate en cómo llegó: el formato antiguo de seis elementos siguió siendo válido, así que esta protección es algo que quien firma decide activar y no algo que el formato garantice.
Para los mensajes estructurados que los puentes se pasan de verdad, EIP-712 define un separador de dominio. Puede llevar un nombre, una versión, el chain ID y la dirección del contrato verificador, más un salt como separador de último recurso, y dice que una billetera debería negarse a firmar cuando el chain ID no coincide con la cadena en la que el usuario está realmente. Otra cadena, otro contrato, otra versión, otro mensaje. Eso es lo que significa la separación de dominios en la práctica: meter el destino dentro de lo que se firma.
La separación de dominios sigue sin impedir que el mismo mensaje se entregue dos veces al mismo destino. EIP-712 lo dice él mismo: el estándar cubre la firma y no incluye protección contra repetición, así que las aplicaciones tienen que rechazar el duplicado o hacer idempotente la acción autorizada. Ese trabajo corresponde a un nonce, a un número de secuencia o a un registro de mensajes ya consumidos.
IBC enseña el patrón completo ya montado. La entrega exactamente una vez es una propiedad declarada del protocolo: cada paquete lleva un número de secuencia, la cadena receptora escribe un acuse bajo ese número y un paquete cuyo acuse ya existe queda rechazado. La especificación señala que es el mismo problema de números de secuencia que con los mensajes firmados, solo que con el cliente ligero en el papel de firmante. Verificar sin deduplicar es medio puente.
Las claves de actualización están por encima de cualquier otro supuesto
Todo lo anterior describe la regla que un puente aplica hoy. La clave de actualización decide quién puede sustituir esa regla mañana.
La mayoría de los contratos de puente son proxies, y ERC-1967 estandariza dónde guarda un proxy su cableado: una ranura de almacenamiento para la dirección de implementación a la que delega y otra para la dirección de admin autorizada a cambiar esa implementación. Una transacción del admin apunta el proxy a código nuevo, y el código nuevo puede definir la validez como le apetezca.
Eso convierte la clave de actualización en un superconjunto de todos los demás riesgos de esta página. Un conjunto de validadores de nueve claves, un cliente ligero, una ventana de impugnación: todo eso puede sustituirlo quien controle la ranura de admin. El techo honesto de la seguridad de un puente es el más débil entre su modelo de verificación y su vía de actualización.
El consuelo es que precisamente esto se puede comprobar. El estándar te dice dónde mirar y pide que los cambios en esas ranuras emitan eventos: Upgraded cuando cambia la implementación y AdminChanged cuando cambia el admin. Lee la ranura de admin. Mira si contiene una única cuenta externa, una multifirma o un timelock, y si es un timelock, cuánto dura el retardo y quién puede cancelarlo.
Las pausas y los cambios de parámetros merecen la misma lectura. El poder de detener un puente o de subir un límite de transferencia es menor que el de reescribir las reglas, pero sigue siendo una clave en manos de alguien, y un puente que se puede pausar se puede pausar con tu transferencia a medio camino.
En resumen
El riesgo de un puente se ordena limpiamente en cuanto preguntas quién verifica. Un conjunto externo de validadores es un sistema aparte cuyo umbral es su presupuesto de seguridad, y ese umbral solo se sostiene si las claves que hay detrás pueden fallar de forma independiente. Los clientes ligeros trasladan el supuesto al consenso de la cadena de origen y a la corrección del código del cliente; los diseños optimistas lo trasladan a que al menos un vigilante siga vivo y sin trabas durante toda la ventana. La protección contra repetición es un requisito distinto: el destino tiene que formar parte de lo firmado, y cada mensaje necesita una secuencia o un acuse. Por encima de todo está la clave de actualización, capaz de sustituir el resto en una sola transacción. Esas cinco respuestas, y no la marca de la interfaz, son lo que confías al cruzar un puente.
Lecturas relacionadas
Otros artículos de Bitbase sobre este tema:
- Desvinculación y retiros del staking: cómo recuperar tus tokens
- Descentralización de validadores: coeficiente de Nakamoto, diversidad de clientes y concentración
- Economía de validadores: comisión, ingresos por tarifas y punto de equilibrio
Aviso legal: Este artículo es contenido educativo de Bitbase Academy y se ofrece solo con fines informativos. No constituye asesoramiento de inversión, negociación, fiscal ni financiero. Los criptoactivos son volátiles; evalúa tu propio riesgo. Redactado en agosto de 2026; consulta la información oficial más reciente.
Fuentes
[1] Ethereum.org, developer documentation, Bridges ethereum.org
[2] Chainalysis, Vulnerabilities in Cross-chain Bridge Protocols Emerge as Top Security Risk chainalysis.com
[3] EIP-155: Simple replay attack protection eips.ethereum.org
[4] EIP-712: Typed structured data hashing and signing eips.ethereum.org
[5] ERC-1967: Proxy Storage Slots eips.ethereum.org
[6] IBC-Go documentation, protocol overview docs.cosmos.network
[7] Inter-Blockchain Communication Protocol, ICS-004: Channel and Packet Semantics github.com
