Compromisos de los Modelos de Consenso para la Interoperabilidad: PoW, PoS, DPoS y BFT en la Seguridad de Puentes Cross-Chain

Más de 2.3 mil millones de dólares fueron drenados de los puentes cross-chain solo en la primera mitad de 2025, superando ya el total de todo el año 2024. Mientras que gran parte de la conversación de la industria se centra en las auditorías de smart contracts y la gestión de claves multisig, una vulnerabilidad más silenciosa pero igualmente crítica a menudo no se examina: el desajuste entre cómo las diferentes blockchains alcanzan el consenso y cómo los puentes asumen que lo hacen.

Cada puente cross-chain realiza suposiciones implícitas sobre la finalidad. Cuando esas suposiciones chocan con el modelo de consenso real de una cadena de origen o destino, los atacantes encuentran ventanas para explotarlas. Comprender cómo difieren los mecanismos de consenso PoW, PoS, DPoS y BFT —y cómo esas diferencias se traducen en cascada en las opciones de diseño de puentes y la selección de protocolos de mensajería— es uno de los temas más importantes en la infraestructura Web3 actual.

Qué significa realmente la finalidad para los puentes

Antes de comparar los tipos de consenso, ayuda a definir qué necesitan realmente los puentes de la capa de consenso de una cadena: finalidad —la garantía de que una transacción confirmada no puede ser revertida.

La finalidad viene en dos variantes:

• Finalidad probabilística: Una transacción se vuelve más segura con el tiempo a medida que se añaden más bloques encima de ella, pero la irreversibilidad nunca es matemáticamente absoluta. Bitcoin es el ejemplo canónico.
• Finalidad determinista (instantánea): Una vez que un bloque es confirmado por una supermayoría de validadores, no puede ser revertido. La mayoría de las cadenas basadas en BFT ofrecen esta garantía.

Para los puentes, esta distinción es enorme. Un puente que considera confirmada una transferencia de Bitcoin después de seis bloques está haciendo una apuesta probabilística. Un puente que confirma una transferencia IBC de Cosmos tras la confirmación de un solo bloque se basa en garantías deterministas integradas en el motor de consenso CometBFT.

Cuando los modelos de finalidad difieren entre las cadenas conectadas, los puentes deben esperar lo suficiente para ser estadísticamente seguros o aceptar un riesgo elevado de reversión. Errar en esto le ha costado a la industria miles de millones.

PoW: Seguridad profunda, finalidad lenta, poco amigable para los puentes

Las cadenas Proof-of-Work como Bitcoin ofrecen una extraordinaria resistencia Sybil y seguridad probada en batalla en la capa base. El coste de un ataque del 51 % en Bitcoin es enorme —estimado en miles de millones de dólares por hora con las tasas de hash actuales— lo que hace que las reorganizaciones profundas de bloques sean económicamente prohibitivas.

Pero esa seguridad tiene un coste para los diseñadores de puentes:

• Solo finalidad probabilística: No hay un límite estricto donde un bloque de Bitcoin sea "final". Seis confirmaciones (~60 minutos) es una convención, no el protocolo.
• Tiempos de bloque lentos: El tiempo medio de bloque de 10 minutos de Bitcoin significa que los puentes deben esperar una hora o aceptar el riesgo de reversión.
• Ventana de reorganización: Cualquier puente que procese depósitos antes de una confirmación profunda es vulnerable a ataques de doble gasto mediante la reorganización de la blockchain.

El peligro real surge cuando una cadena PoW con una potencia de hash débil (no Bitcoin, sino cadenas PoW más pequeñas) se conecta a un ecosistema DeFi de alto valor. Ethereum Classic sufrió un ataque del 51 % en 2020, y cualquier puente que tratara los depósitos de ETC como finales demasiado rápido habría sido vulnerable en ese momento.

Protocolo de mensajería más adecuado: Debido a que las cadenas PoW carecen de soporte de clientes ligeros para una verificación eficiente de pruebas, los puentes que se conectan a ellas suelen depender de validadores externos o comités de oráculos en lugar de pruebas de finalidad criptográfica. Protocolos como Axelar (red de validadores asegurada por DPoS) y el modelo Oracle + Relayer de LayerZero se adaptan mejor aquí que los puentes de tipo cliente ligero como IBC, ya que estos últimos requieren que la cadena de origen tenga finalidad instantánea para un funcionamiento eficiente.

PoS: Finalidad mejorada, pero complejidad en los puntos de control

La transición de Ethereum a Proof-of-Stake trajo mejoras significativas para el diseño de puentes cross-chain. La capa de consenso de Ethereum (anteriormente Ethereum 2.0) utiliza una combinación de elección de bifurcación LMD-GHOST y finalización Casper FFG, lo que proporciona finalidad económica cada dos épocas (~12.8 minutos).

Para los puentes, esta es una mejora significativa sobre Bitcoin:

• Los puntos de control finalizados son comprometidos criptográficamente por una supermayoría de ETH en staking.
• Una reorganización más allá de un punto de control finalizado requeriría el slashing de más de un tercio de todo el ETH en staking —actualmente decenas de miles de millones de dólares.
• Los clientes ligeros pueden verificar las firmas del Comité de Sincronización de Ethereum, permitiendo diseños de puentes con menos necesidad de confianza.

Sin embargo, PoS introduce sus propias complicaciones:

• Rotación del conjunto de validadores: Los clientes ligeros de los puentes deben seguir los cambios en el conjunto de validadores. Un cliente ligero desactualizado puede aceptar pruebas firmadas por un conjunto de validadores que ya no existe.
• El slashing no es un castigo instantáneo: Las penalizaciones económicas desincentivan los ataques pero no los previenen por completo en la pequeña ventana antes de la finalización.
• Los puntos de control de finalidad crean latencia: Los puentes que esperan la finalidad de Casper FFG añaden entre 12 y 13 minutos a los tiempos de las transacciones cross-chain —aceptable para transferencias grandes, frustrante para los usuarios de DeFi.

Protocolo de mensajería más adecuado: El modelo PoS de Ethereum es cada vez más compatible con los diseños de puentes basados en pruebas de conocimiento cero (ZK-proofs). Protocolos emergentes como Telepathy de Succinct utilizan ZK-SNARKs para verificar las firmas del Comité de Sincronización de Ethereum on-chain, permitiendo puentes con confianza minimizada con una latencia razonable. El soporte de LayerZero v2 para DVN (redes de verificación descentralizadas) basadas en pruebas ZK también se alinea bien con las cadenas PoS que exponen pruebas de estado criptográficas verificables.

DPoS: Consenso Rápido, Riesgo del Conjunto de Validadores

Los sistemas de Prueba de Participación Delegada (DPoS) — utilizados por EOS, BNB Chain y, fundamentalmente, por la propia red de validadores de Axelar — introducen un conjunto de validadores elegidos más pequeño para lograr un consenso más rápido.

Ventajas de DPoS para los puentes:

• Tiempos de bloque rápidos y finalidad casi instantánea: Con 21 a 101 validadores activos, BNB Chain confirma bloques en ~3 segundos con una finalidad práctica en ~15 segundos.
• Conjuntos de validadores predecibles: Los puentes pueden mantener pruebas más ligeras porque el conjunto de validadores cambia en un ciclo de elección más lento.
• Menor sobrecarga de cómputo: Menos validadores significan menos firmas que verificar.

Pero DPoS comprime la superficie de ataque:

• Riesgo de colusión: Una supermayoría de delegados elegidos — potencialmente tan solo 11 de 21 en algunas cadenas — puede teóricamente coludir para falsificar el consenso. Se han documentado ataques de compra de votos en las elecciones de delegados en EOS.
• Dinámicas de cartel: En la práctica, un pequeño número de entidades a menudo controla múltiples ranuras de delegados, reduciendo la descentralización.
• Cascada de compromiso de claves: Si un puente depende del conjunto de validadores DPoS y varios validadores se ven comprometidos simultáneamente, la seguridad del puente colapsa junto con la cadena subyacente.

Axelar Network es un caso de estudio interesante: es en sí misma una cadena DPoS (construida sobre el SDK de Cosmos con consenso CometBFT y más de 75 validadores activos) que sirve como hub para el paso de mensajes entre cadenas. La seguridad de cada mensaje que Axelar retransmite está respaldada en última instancia por la seguridad económica del staking de AXL — un diseño deliberado que hace que el modelo de seguridad del puente sea explícito y cuantificable.

Protocolo de mensajería más adecuado: Las cadenas DPoS se emparejan naturalmente con arquitecturas de interoperabilidad de tipo hub-and-spoke como Axelar, donde una capa de consenso DPoS construida a propósito asegura los mensajes cross-chain. Los protocolos punto a punto como IBC también pueden funcionar si la cadena DPoS expone interfaces de cliente ligero compatibles, aunque el conjunto de validadores más pequeño significa que el umbral de seguridad criptográfica es más bajo que en redes PoS más descentralizadas.

BFT: Finalidad Instantánea, el Entorno Nativo de IBC

El consenso de Tolerancia a Faltas Bizantinas (BFT) — particularmente CometBFT (anteriormente Tendermint), utilizado en todo el ecosistema Cosmos — es el modelo de consenso más amigable para los puentes que se encuentra actualmente en producción.

Garantías de BFT:

• Finalidad determinista e instantánea: Un bloque se compromete irreversiblemente en el momento en que una supermayoría (2/3+) de validadores lo firma. No hay un período de espera probabilístico.
• Sin bifurcaciones por diseño: Bajo condiciones normales de red, las cadenas BFT no se bifurcan. Un solo bloque confirmado es la cadena canónica.
• Detección de mal comportamiento: El protocolo de cliente ligero de IBC incluye el envío de pruebas de mal comportamiento — si un conjunto de validadores incurre en equivocación (firma dos bloques conflictivos), se puede enviar una prueba on-chain, congelando el cliente ligero para evitar daños mayores.

Estas propiedades son exactamente sobre las que se diseñó el protocolo de Comunicación Inter-Blockchain (IBC). IBC minimiza la confianza porque:

1. Se basa en la verificación de clientes ligeros de las cabeceras de la cadena contraparte, no en validadores externos.
2. La finalidad determinista de BFT significa que el cliente ligero nunca tiene que cubrirse contra reorganizaciones (reorgs).
3. No hay custodios, ni multisigs — solo pruebas criptográficas de inclusión de estado.

IBC v2, lanzado en marzo de 2025, extiende este modelo a Ethereum — utilizando ZK-proofs para que los puntos de control de finalidad PoS de Ethereum sean verificables dentro de un contexto de cliente ligero de IBC. Este es un desarrollo histórico: el modelo de confianza nativo de BFT se está adaptando para envolver cadenas PoS, expandiendo drásticamente la superficie de seguridad de IBC.

La contrapartida: el consenso BFT escala mal. A medida que los conjuntos de validadores crecen más allá de unos pocos cientos de nodos, la sobrecarga de comunicación para recolectar firmas crece cuadráticamente. Esta es la razón por la cual las cadenas BFT tienden a tener conjuntos de validadores más pequeños y seleccionados — lo que reintroduce las preocupaciones de centralización que enfrenta DPoS.

Protocolo de mensajería más adecuado: IBC es la elección canónica para las cadenas BFT y el estándar de oro para la comunicación cross-chain con confianza minimizada. Hyperlane también es muy adecuado aquí: sus Módulos de Seguridad Interchain (ISMs) pueden configurarse para verificar directamente el estado de la cadena BFT, y su modelo de retransmisor sin permisos significa que cualquiera puede operar la infraestructura para el paso de mensajes de BFT a BFT.

Emparejamiento de Protocolos de Mensajería con Tipos de Consenso

Aquí hay un marco práctico para seleccionar un protocolo de mensajería basado en los tipos de consenso de las cadenas conectadas:

LayerZero v2 funciona con prácticamente cualquier cadena, pero requiere una configuración cuidadosa de las DVN. Su pila de seguridad modular — donde los desarrolladores de aplicaciones seleccionan qué Redes de Verificadores Descentralizados (DVN) validan sus mensajes — lo hace agnóstico de la cadena a costa de trasladar las decisiones de seguridad a los desarrolladores. Es ideal para entornos heterogéneos donde no domina un único modelo de finalidad.

Axelar está construido específicamente para cadenas donde la seguridad económica externa es aceptable. Su red de validadores DPoS maneja explícitamente el desajuste de consenso: los validadores de Axelar observan la finalidad de la cadena de origen (independientemente de cómo la defina dicha cadena) antes de retransmitir los mensajes. Esto lo hace versátil, pero introduce el propio conjunto de validadores de Axelar como una suposición de confianza. Es ideal para conectar cadenas PoW o PoS al ecosistema más amplio.

IBC es la opción que más minimiza la confianza, pero requiere que las cadenas de origen tengan una finalidad rápida y determinista e implementaciones de cliente ligero compatibles. Con la extensión del soporte de IBC v2 a Ethereum, su alcance está creciendo. Es ideal para conexiones de BFT a BFT y, cada vez más, para conexiones de BFT a PoS a través de puentes ZK.

Hyperlane ofrece la mayor flexibilidad para el desarrollador a través de ISMs configurables. Los equipos pueden elegir un ISM multifirma (basado en comités, similar al modelo de Axelar) o un ISM de cliente ligero ZK (similar a IBC) dependiendo del tipo de consenso de la cadena de origen. Es ideal para equipos que construyen rollups soberanos o cadenas de aplicaciones (appchains) que necesitan definir sus propios parámetros de seguridad.

Chainlink CCIP se basa en la red de oráculos descentralizados (DON) de Chainlink para la verificación de mensajes cross-chain, lo que lo hace relativamente agnóstico al consenso. Es ideal para aplicaciones empresariales y protocolos DeFi que ya utilizan los feeds de precios de Chainlink, donde la simplicidad de la integración y la confianza en la marca son importantes.

El costo oculto de la finalidad desajustada

Los hackeos de puentes que definieron la era 2022-2024 —Ronin ($625M), Wormhole ($320M), Nomad ($190M)— compartieron un hilo común: cada uno hizo suposiciones peligrosas sobre la finalidad de las transacciones en las cadenas conectadas.

Los validadores de Ronin confirmaron depósitos antes de que hubiera transcurrido la finalidad on-chain adecuada. La ventana de prueba de fraude de Nomad no tuvo en cuenta el riesgo de reordenamiento (reorg) en las cadenas conectadas. Estos no fueron solo errores de contratos inteligentes; fueron desajustes arquitectónicos entre los modelos de finalidad.

A medida que la industria procesa más de $2.3 mil millones en pérdidas de la primera mitad de 2025, la lección es clara: la seguridad de los puentes no se trata solo de cuántos auditores revisaron el contrato. Se trata de si las suposiciones de finalidad del puente coinciden con las garantías reales de cada cadena conectada —incluido el eslabón más débil de la red.

Mirando hacia el futuro: Las pruebas ZK como el adaptador universal

El desarrollo más emocionante en la seguridad de los puentes es el surgimiento de clientes ligeros basados en pruebas ZK como una capa de verificación de finalidad agnóstica al consenso. Proyectos como Succinct Labs, Polyhedra y la iniciativa IBC v2 están construyendo circuitos ZK que pueden verificar firmas de puntos de control de PoS, conjuntos de validadores BFT e incluso cabeceras de bloques PoW —todo dentro de contratos inteligentes on-chain.

Si la verificación basada en ZK madura como se espera a lo largo de 2025 y 2026, podría resolver la tensión central que explora este artículo: los puentes ya no tendrían que elegir entre la seguridad de las pruebas criptográficas (que requiere finalidad determinista) y la flexibilidad de los validadores externos (que maneja cualquier modelo de finalidad pero añade suposiciones de confianza).

Hasta que llegue ese futuro, la guía práctica es clara: conozca los modelos de consenso de sus cadenas, seleccione protocolos de mensajería que coincidan con sus garantías de finalidad y nunca construya un puente que asuma una finalidad determinista donde solo existe una finalidad probabilística.

---

BlockEden.xyz proporciona infraestructura de nodos de nivel empresarial y servicios de API para más de 27 redes blockchain, incluidas las cadenas Sui, Aptos, Ethereum y Cosmos. Ya sea que esté creando una aplicación cross-chain o necesite un acceso RPC confiable para la infraestructura de puentes, explore nuestro mercado de APIs para construir sobre bases diseñadas para la fiabilidad de producción.