Cada vez que envías una transacción de criptomonedas, recibes un pago o interactúas con un contrato inteligente, una red de ordenadores que no se conocen ni confían entre sí debe confirmar que tu transacción es válida y debe registrarse permanentemente. Algunos de esos ordenadores pueden estar desconectados. Otros pueden estar controlados por personas malintencionadas que envían información falsa deliberadamente. Sin embargo, la cadena de bloques debe llegar a la misma conclusión correcta en cada nodo honesto.
El mecanismo que hace esto posible es la tolerancia a fallos bizantinos (BFT). Es uno de los conceptos más importantes y menos comprendidos en los sistemas distribuidos, ya que constituye la base de seguridad subyacente. la tecnología blockchainfinanzas descentralizadas, libros de contabilidad empresariales e Internet de las cosas.
Esta guía abarca la tolerancia a fallos bizantinos desde sus principios básicos hasta sus implementaciones modernas más avanzadas, incluyendo su comparación con la prueba de trabajo y la prueba de participación, los vectores de ataque específicos contra los que protege, los protocolos que se basan en ella actualmente y los desafíos que los investigadores aún están trabajando para resolver.
El problema de los generales bizantinos: dónde empezó todo.
Para comprender la tolerancia a fallos bizantinos, es necesario entender el problema que pretende resolver. El problema de los generales bizantinos fue descrito formalmente por primera vez en 1982 por los informáticos Leslie Lamport, Robert Shostak y Marshall Pease en un artículo titulado «El problema de los generales bizantinos», publicado en la revista ACM Transactions on Programming Languages and Systems.
El problema se plantea mediante una analogía militar. Imaginemos varias divisiones de un ejército bizantino rodeando una ciudad enemiga. Cada división está al mando de un general y solo pueden comunicarse entre sí mediante mensajeros. Deben acordar un plan de acción común: atacar o retirarse. Si atacan todas juntas, ganan. Si se retiran todas juntas, sobreviven. Pero si algunas atacan mientras otras se retiran, son aniquiladas.
La complicación reside en que algunos generales podrían ser traidores. Un traidor podría enviar mensajes distintos a diferentes generales, ordenando a algunos "atacar" y a otros "retirarse", con el objetivo deliberado de impedir un acuerdo. Los generales leales no pueden simplemente ignorar los mensajes que sospechan que son falsos, ya que no pueden identificar de inmediato a los generales traidores.
El problema plantea la siguiente pregunta: ¿Qué algoritmo pueden utilizar los generales leales para garantizar que todos lleguen a la misma decisión, incluso cuando una parte de los generales son traidores que intentan activamente provocar desacuerdos?
Lamport, Shostak y Pease demostraron que existe una solución posible si y solo si más de dos tercios de los generales son leales. Dicho de otro modo: un sistema de n nodos puede tolerar como máximo f nodos defectuosos o maliciosos, siempre que n sea al menos 3f + 1. Con menos de dos tercios de participantes honestos, ningún algoritmo puede garantizar un acuerdo.
Este resultado matemático se convirtió en la base teórica de todos los algoritmos de consenso BFT posteriores.
Lea también: Cómo el hash protege la tecnología blockchain
¿Qué es la tolerancia a fallas bizantinas?
La tolerancia a fallos bizantinos se refiere a la propiedad de un sistema distribuido que le permite seguir funcionando correctamente y alcanzar un consenso incluso cuando algunos de sus nodos fallan de forma arbitraria, como enviar mensajes contradictorios o falsos, responder de forma inconsistente a diferentes participantes o comportarse de forma maliciosa para interrumpir la red.
El término «bizantino» se refiere específicamente a la clase de fallo más grave: un comportamiento arbitrario, antagónico e inconsistente. Esto es mucho más difícil de gestionar que un simple fallo por caída del sistema (en el que un nodo deja de responder por completo), ya que un nodo bizantino puede parecer que se comporta correctamente en ocasiones, mientras que en otros momentos socava activamente el consenso.
En el contexto de los la tecnología blockchainLa tolerancia a fallos bizantinos significa que la red blockchain puede mantener su integridad y seguir validando las transacciones correctamente incluso cuando algunos validadores o nodos están comprometidos, fuera de línea o son deliberadamente maliciosos.
La regla establecida en el artículo de Lamport se mantiene: mientras al menos dos tercios de los nodos de la red sean honestos y funcionen correctamente, un sistema BFT alcanzará el consenso adecuado. En el momento en que un solo atacante controla más de un tercio de los nodos, las garantías de seguridad de los protocolos BFT clásicos comienzan a fallar.
Obtén la tarjeta criptográfica UPay
Experimente lo mejor del pago en línea y transacciones de criptomonedas fluidas.
RegistrarseTolerancia a fallos no bizantina frente a bizantina: una distinción crucial
No todas las tolerancias a fallos son iguales. Comprender la diferencia entre la tolerancia a fallos no bizantina y la bizantina aclara por qué esta última es más difícil y por qué es tan importante para la tecnología blockchain.
Tolerancia a fallos no bizantinos (por colisión) Gestiona el caso más sencillo en el que los nodos pueden fallar deteniéndose: se bloquean, se desconectan o se vuelven inaccesibles. El sistema debe continuar aunque algunos nodos estén inactivos. Esto es más fácil de gestionar porque un nodo bloqueado no envía mensajes ni causa confusión activa. Sistemas como Apache ZooKeeper y las bases de datos distribuidas más antiguas se diseñaron teniendo en cuenta la tolerancia a fallos por bloqueo.
Tolerancia a fallas bizantinas Aborda el caso más complejo en el que los nodos fallidos pueden comportarse de forma arbitraria, enviando mensajes erróneos, contradictorios o estratégicamente engañosos a diferentes partes de la red. Un nodo bizantino no se limita a permanecer inactivo; participa activamente en acciones diseñadas para generar confusión o impedir el consenso. Las redes blockchain están expuestas a este problema más complejo porque operan en entornos abiertos y sin permisos, donde cualquiera puede ejecutar un nodo, incluidos los adversarios.
En el ámbito específico de la tecnología blockchain, las fallas bizantinas incluyen: un minero que incluye transacciones fraudulentas en un bloque propuesto, un validador que firma bloques conflictivos para intentar una bifurcación, un nodo que envía información diferente sobre el orden de las transacciones a diferentes pares, y nodos que ejecutan ataques de doble gasto al transmitir transacciones conflictivas simultáneamente a diferentes partes de la red.
Un sistema que tolera fallos por caída del sistema pero no fallos bizantinos no sería adecuado para una cadena de bloques pública, donde los nodos son operados por partes desconocidas y potencialmente adversarias.
Cómo se logra la BFT: Los mecanismos principales
La tolerancia a fallos bizantinos se logra mediante la combinación de tres mecanismos principales que trabajan juntos para permitir que los nodos honestos lleguen a un acuerdo a pesar de la presencia de participantes adversarios.
Redundancia
En lugar de depender de un único nodo para registrar o validar una transacción, los sistemas BFT utilizan múltiples nodos redundantes. Siempre que más de dos tercios de estos nodos redundantes sean fiables, el sistema puede identificar y descartar la minoría de mensajes falsos o contradictorios. La redundancia es la base estructural de BFT: es imposible lograr la tolerancia a fallos bizantinos sin utilizar más nodos de los estrictamente necesarios para procesar las transacciones.
Firmas criptográficas
Los protocolos BFT utilizan criptografía de clave pública para autenticar los mensajes entre nodos. Cuando un nodo envía un mensaje (como una votación sobre la validez de un bloque propuesto), lo firma con su clave privada. Otros nodos pueden verificar la firma utilizando la clave pública del remitente, confirmando que el mensaje proviene realmente del remitente declarado y que no ha sido alterado durante la transmisión. Esto previene uno de los ataques bizantinos más peligrosos: que un nodo malicioso suplante la identidad de otro falsificando sus mensajes.
Protocolos de consenso estructurados
Los protocolos de consenso BFT definen reglas precisas sobre cómo los nodos proponen, votan y finalizan nuevos datos. Estos protocolos están diseñados específicamente para que, incluso si algunos nodos emiten votos contradictorios, la mayoría honesta pueda llegar a la misma respuesta final. La estructura del protocolo elimina la ambigüedad: existe un proceso definido para lo que sucede cuando los votos entran en conflicto, cuando falla un líder y cuando los nodos discrepan sobre el estado actual.
Las tres propiedades que definen el consenso BFT
Todo protocolo de consenso BFT, independientemente de su diseño específico, debe satisfacer tres propiedades fundamentales:
Seguridad Esto significa que ningún par de nodos correctos (honestos) jamás decidirán valores diferentes. Si un nodo honesto confirma una transacción como válida, ningún otro nodo honesto la confirmará como inválida. La seguridad garantiza que la cadena de bloques no se bifurque en historiales contradictorios entre participantes honestos.
Vivacidad Esto significa que el sistema finalmente progresa. Si suficientes nodos correctos envían una transacción, esta se confirmará. La red no se bloquea permanentemente. La disponibilidad garantiza que los participantes honestos no se vean bloqueados indefinidamente e impidan que se procesen sus transacciones.
Un acuerdo Esto significa que si un nodo correcto entrega una transacción, entonces todos los nodos correctos entregan esa misma transacción. Todos los nodos honestos ven los mismos datos en el mismo orden.
La seguridad y la disponibilidad pueden entrar en conflicto. El famoso teorema CAP en sistemas distribuidos demuestra que ningún sistema distribuido puede garantizar simultáneamente la consistencia, la disponibilidad y la tolerancia a particiones. Los protocolos BFT establecen compromisos deliberados. La mayoría prioriza la seguridad sobre la disponibilidad: se detendrán en lugar de confirmar un resultado potencialmente erróneo si demasiados nodos se comportan incorrectamente.
Lea también: ¿Qué es el consenso en Blockchain?
Tipos de algoritmos de tolerancia a fallos bizantinos
BFT ha evolucionado sustancialmente desde el artículo de 1982. Actualmente, el campo incluye varias familias de protocolos distintas, cada una con diferentes características de rendimiento, supuestos de confianza y contextos de implementación.
Tolerancia práctica a fallas bizantinas (PBFT)
La tolerancia a fallos bizantinos práctica fue introducida por Barbara Liskov y Miguel Castro en el MIT en 1999. Fue el primer algoritmo BFT lo suficientemente práctico para su implementación real en sistemas distribuidos, resolviendo el problema en redes asíncronas con una sobrecarga baja en comparación con los trabajos académicos anteriores sobre BFT.
PBFT funciona a través de tres fases de comunicación entre nodos:
Fase de preparación previa: El nodo principal (líder) recibe una solicitud del cliente, le asigna un número de secuencia y difunde un mensaje de pre-preparación a todos los demás nodos (llamados réplicas). Este mensaje contiene la solicitud, el número de secuencia y el número de vista actual.
Fase de preparación: Cada réplica que acepta la pre-preparación transmite un mensaje de preparación a todas las demás réplicas. Una réplica pasa a la siguiente fase solo cuando ha recibido mensajes de preparación coincidentes de al menos 2f nodos (donde f es el número máximo de nodos defectuosos que tolera el sistema). Este requisito de quórum impide que un líder defectuoso engañe a diferentes réplicas para que acepten números de secuencia distintos.
Fase de confirmación: Una vez que un nodo ha recopilado suficientes mensajes de preparación coincidentes, difunde un mensaje de confirmación. Una réplica ejecuta la solicitud y responde al cliente solo cuando ha recibido mensajes de confirmación de al menos 2f + 1 nodos. Este quórum final garantiza que, incluso si algunos nodos que enviaron mensajes de confirmación fallan posteriormente, existen suficientes nodos confirmados para garantizar la durabilidad del resultado.
Un cliente acepta un resultado cuando recibe f + 1 respuestas coincidentes, lo que garantiza que al menos un nodo honesto haya confirmado el resultado.
La complejidad de comunicación de PBFT es O(n²), lo que significa que el número de mensajes crece cuadráticamente con el número de nodos. Esto es manejable para decenas o cientos de nodos, pero se vuelve prohibitivo a gran escala. Además, PBFT depende de un conjunto fijo y conocido de validadores, por lo que resulta más adecuado para entornos de blockchain con permisos o de consorcio.
PBFT puede tolerar que hasta un tercio (33%) de los nodos sean bizantinos. Se ha demostrado matemáticamente que este umbral es el máximo teórico para los protocolos BFT clásicos.
Uso del consenso derivado de PBFT por parte de Hyperledger Fabric es el ejemplo empresarial más destacado. Fabric utiliza un servicio de pedidos (anteriormente basado en PBFT, ahora basado en Raft con una ruta de actualización BFT a través de SmartBFT) que proporciona un alto rendimiento y baja latencia para aplicaciones empresariales. Walmart utilizó Hyperledger Fabric para rastrear productos alimenticios desde la granja hasta el estante, demostrando la implementación práctica de BFT en un entorno real de cadena de suministro.
Acuerdo bizantino federado (FBA)
El Acuerdo Bizantino Federado adopta un enfoque fundamentalmente diferente al problema de la confianza. En lugar de exigir que todos los validadores conozcan y estén de acuerdo en el conjunto completo de validadores de confianza, el FBA permite que cada nodo defina su propio "segmento de quórum", el subconjunto de otros nodos en los que confía personalmente.
El sistema alcanza el consenso global cuando estos segmentos de confianza individuales forman conjuntos superpuestos. Si el nodo A confía en los nodos B y C, y el nodo B confía en los nodos A y D, su confianza superpuesta crea un quórum global implícito, aunque ninguna autoridad central lo haya definido.
FBA es el mecanismo de consenso subyacente de la red Stellar y, en una versión modificada, de la red Ripple. La implementación de FBA en Stellar logra la finalización de las transacciones en tres a cinco segundos y admite miles de transacciones por segundo, lo que la hace práctica para pagos transfronterizos. MoneyGram y otros proveedores de remesas utilizan Stellar específicamente porque su consenso FBA proporciona la finalización rápida y confiable que requieren las aplicaciones de pago.
El enfoque FBA presenta una disyuntiva diferente a la de PBFT: permite una estructura de confianza más descentralizada, pero requiere un diseño cuidadoso de las secciones de quórum para garantizar que se mantenga la propiedad de acuerdo global. Si las secciones de quórum se definen incorrectamente, partes de la red pueden formar grupos de consenso desconectados que acuerden estados diferentes.
Cosas calientes
HotStuff es un protocolo de consenso BFT presentado por los investigadores Maofan Yin, Dahlia Malkhi, Michael Reiter, Guy Golan Gueta e Ittai Abraham en 2019. Se convirtió en una herramienta muy influyente como base para el protocolo LibraBFT de Facebook (utilizado en el proyecto de cadena de bloques Diem) y ha servido de base para el diseño de múltiples sistemas de consenso de cadena de bloques modernos.
La principal innovación de HotStuff reside en lograr una complejidad de comunicación lineal, O(n), en lugar de la complejidad cuadrática O(n²) de PBFT. Esto se consigue mediante un diseño basado en un líder, donde este recopila votos en firmas umbral, agregando n votos individuales en una única prueba compacta. De esta forma, la sobrecarga de comunicación no se dispara a medida que crece el conjunto de validadores.
HotStuff utiliza una estructura de tres fases (preparación, pre-compromiso, confirmación) que se corresponde conceptualmente con las fases de PBFT, pero que funciona de forma más eficiente mediante la segmentación: mientras se confirma un bloque, ya se está proponiendo el siguiente, lo que mejora drásticamente el rendimiento.
HotStuff sacrifica una latencia ligeramente mayor (tres viajes de ida y vuelta frente a dos en PBFT) a cambio de una escalabilidad notablemente superior. Para conjuntos de validadores grandes, de cientos o miles de nodos, esta compensación resulta muy ventajosa. El algoritmo CometBFT del ecosistema Cosmos (anteriormente Tendermint Core) y el consenso utilizado en Aptos y Sui se basan en diseños de la familia HotStuff.
Menta tierna y CometaBFT
Tendermint es un algoritmo de consenso BFT diseñado específicamente para su uso en blockchain, presentado por Jae Kwon en 2014. Separa la capa de consenso de la capa de aplicación a través de la Interfaz de Blockchain de Aplicación (ABCI), lo que permite que cualquier aplicación utilice el consenso Tendermint sin necesidad de construir su propia infraestructura de red y consenso.
Tendermint logra el consenso por rondas. En cada ronda, un proponente difunde un bloque. Los validadores votan en dos fases (prevoto y precompromiso). Un bloque se confirma cuando al menos dos tercios de los validadores envían votos de precompromiso coincidentes. Si la ronda falla (debido a un fallo del proponente o a una red demasiado lenta), comienza una nueva ronda con un nuevo proponente.
Tendermint ofrece finalidad instantánea: una vez que se confirma un bloque, no se puede revertir sin violar el supuesto de mayoría honesta de dos tercios. Esto representa una ventaja significativa sobre los sistemas de finalidad probabilística, como la prueba de trabajo, donde una transacción solo se considera definitiva después de que se agregan varios bloques posteriores.
Tendermint gestiona miles de transacciones por segundo con una latencia aproximada de un segundo. En 2023, cambió su nombre a CometBFT para reflejar un modelo de gobernanza comunitaria más amplio. Cosmos Hub y todas las cadenas basadas en Cosmos SDK (que superarán las 100 cadenas activas en 2025) utilizan CometBFT como capa de consenso. Un ejemplo notable en producción fue la detención de la cadena Cosmos Hub v17.1, que no se debió a un fallo en la prueba de seguridad principal de CometBFT, sino a un error de software en el código de actualización del conjunto de validadores en torno a EndBlock, lo que demuestra cómo las garantías de BFT se ejecutan dentro de una pila de implementación completa, no de forma aislada en teoría.
BFT en Prueba de Participación: Casper y Ethereum
La transición de Ethereum a la prueba de participación mediante la fusión en septiembre de 2022 introdujo Casper FFG (Friendly Finality Gadget) combinado con la opción de bifurcación LMD-GHOST, formando juntos el protocolo de consenso Gasper. Casper proporciona finalidad al estilo BFT sobre un conjunto de validadores de prueba de participación.
Casper funciona como un mecanismo de finalidad integrado en la producción de bloques. Los validadores votan los puntos de control cada 32 intervalos (aproximadamente 6.4 minutos). Cuando dos tercios del total de ETH apostado han votado a favor de un punto de control, este se considera "justificado". Si dos puntos de control consecutivos se justifican, el primero se considera "finalizado". Los bloques finalizados no pueden revertirse sin que el atacante queme al menos un tercio de todo el ETH apostado, lo que crea una sólida garantía económica contra la transferencia de bloques.
Este mecanismo de penalización económica es la adaptación de Ethereum del BFT clásico: en lugar de garantías puramente matemáticas, la finalidad se impone mediante el coste económico de las malas prácticas. Si un validador firma bloques conflictivos, pierde toda su participación (es penalizado). La amenaza de perder un capital sustancial alinea el comportamiento honesto con el interés económico propio.
Tolerancia a fallos bizantinos en la prueba de trabajo
La prueba de trabajo de Bitcoin logra una forma probabilística de tolerancia a fallos bizantinos mediante un mecanismo diferente al de los protocolos BFT clásicos. El documento técnico de Bitcoin de Satoshi Nakamoto de 2008 introdujo la prueba de trabajo como una solución al problema de los generales bizantinos en un entorno sin permisos, donde los participantes son desconocidos y no pueden ser identificados previamente.
En el sistema de prueba de trabajo (PoW) de Bitcoin, la tolerancia a fallos bizantinos implica que, mientras los mineros honestos controlen más del 50 % de la potencia de hash total de la red, un atacante que controle menos del 50 % no puede reescribir el historial de transacciones confirmadas. El coste de un ataque del 51 % aumenta con la tasa de hash de Bitcoin y la dificultad de los problemas de minería.
A diferencia de los protocolos BFT clásicos, que garantizan la finalidad absoluta tras una única ronda de votación, la finalidad de Bitcoin es probabilística: la probabilidad de que una transacción se revierta disminuye exponencialmente con cada bloque adicional que se añade posteriormente. Por este motivo, tradicionalmente se han utilizado confirmaciones de 6 bloques (aproximadamente una hora) para las transacciones grandes de Bitcoin.
La contrapartida es significativa: la prueba de trabajo (PoW) proporciona BFT en un entorno sin permisos a costa de un enorme consumo de energía, una finalidad lenta (de 10 a 60 minutos) y la vulnerabilidad a ataques del 51 % a la que nunca se enfrentan los protocolos BFT clásicos por debajo de su umbral.
Comparación de protocolos BFT: una visión general directa
| Protocolo | Umbral de falla | Finalidad | Complejidad del mensaje | Uso recomendado |
| PBFT (Castro-Liskov) | 1/3 Bizantino | Acceso | O(n al cuadrado) | Redes pequeñas con permisos |
| Cosas calientes | 1/3 Bizantino | Acceso | O(n) lineal | Conjuntos de validadores grandes |
| Menta tierna / CometaBFT | 1/3 Bizantino | Instantáneo (~1s) | O (n) | Cadenas Cosmos, cadenas de bloques públicas |
| Acuerdo bizantino federado | Segmentos de quórum superpuestos | segundos 3-5 | Variable | Redes de pago (Stellar, Ripple) |
| Casper FFG (Ethereum PoS) | 1/3 del ETH apostado | Cada 6.4 min | O(n) con agregación BLS | Cadenas de bloques PoS públicas |
| Prueba de trabajo de Bitcoin | 50% de potencia de hash | Probabilístico (6+ bloques) | Transmisión O(1) | Redes sin permisos ni confianza |
| Algorand BA | 1/3 Bizantino | ~ 4.5 segundos | Sublineal con VRF | Sin permiso y con finalización rápida |
Implementaciones reales de BFT en 2025
Hyperledger Fabric y la cadena de bloques empresarial
Hyperledger Fabric es el marco de blockchain empresarial más implementado en producción. Impulsa el sistema de trazabilidad de alimentos de Walmart, las soluciones de cadena de suministro de IBM y cientos de aplicaciones financieras y logísticas. El servicio de pedidos de Fabric experimentó una evolución significativa: tras abandonar PBFT y adoptar Raft (un consenso tolerante a fallos para implementaciones más sencillas), Fabric introdujo SmartBFT como su servicio de pedidos tolerante a fallos bizantinos para entornos que requieren garantías BFT completas. SmartBFT sigue el patrón de difusión trifásico heredado de PBFT y proporciona un alto rendimiento con baja latencia, adecuado para aplicaciones de nivel empresarial.
Acuerdo Bizantino Federado de Stellar en Pagos Globales
La implementación de FBA de Stellar procesa millones de transacciones diarias, y MoneyGram, Wirex y otras instituciones financieras la utilizan para pagos transfronterizos. El consenso de Stellar logra la liquidación final en tres a cinco segundos, lo que es muchísimo más rápido que la banca corresponsal tradicional (de uno a cinco días) y más rápido que la mayoría de las alternativas blockchain. El modelo FBA permite que cada nodo defina sus propias relaciones de confianza, al tiempo que logra un acuerdo global, lo que hace que el modelo de consenso de Stellar sea especialmente adecuado para una red de pagos donde no todos los participantes confían plenamente entre sí, pero todos desean una liquidación confiable.
Protocolo del Acuerdo Bizantino de Algorand
Algorand emplea un enfoque BFT único llamado Pure Proof of Stake combinado con sorteo criptográfico. En cada ronda de consenso, se selecciona un comité aleatorio de validadores mediante una función aleatoria verificable (VRF). Solo los miembros del comité seleccionados saben que han sido elegidos (y pueden demostrarlo a los demás), lo que hace que los ataques dirigidos contra los miembros del comité sean prácticamente imposibles, ya que el atacante no sabe de antemano a quién atacar.
El protocolo BA de Algorand logra la finalidad en aproximadamente 4.5 segundos, con un rendimiento que supera las 1,000 transacciones por segundo en producción. Su diseño proporciona BFT en un entorno sin permisos y sin el coste energético de la prueba de trabajo, una combinación que lo distingue tanto de Bitcoin como de los sistemas BFT clásicos con permisos.
Ecosistema Cosmos y Cometa BFT
En 2025, el ecosistema Cosmos comprende más de 100 blockchains soberanas, todas ellas utilizando CometBFT como capa de consenso. El protocolo de Comunicación Inter-Blockchain (IBC) se basa en la garantía de finalidad instantánea de CometBFT: las pruebas IBC solo son válidas porque el Cosmos Hub y sus cadenas contraparte pueden demostrar que una transacción se ha finalizado realmente, y no solo que es probable que se finalice. Sin las sólidas garantías de finalidad que proporciona el consenso BFT, la comunicación entre cadenas de este tipo sería mucho más difícil de asegurar. El ecosistema procesa miles de millones de dólares en transferencias diarias de valor entre cadenas, todas ellas protegidas por el consenso tolerante a fallos bizantinos de CometBFT.
BFT de Estambul de Klaytn
Klaytn, implementado por la empresa surcoreana Kakao, utiliza Istanbul BFT (IBFT), que procesa más de 4,000 transacciones por segundo con tiempos de bloque de un segundo. IBFT es una variante de BFT compatible con EVM que permite a Klaytn mantener la compatibilidad con las herramientas de Ethereum, a la vez que logra un rendimiento muy superior al de la capa base de Ethereum. Su arquitectura híbrida público-privada permite a las empresas ejecutar cadenas laterales con permisos, mientras que la cadena principal pública mantiene las garantías de BFT descentralizadas.
Vectores de ataque contra los que se defiende BFT
Comprender contra qué protege BFT aclara su valor y sus limitaciones.
Ataques de doble gasto
En un ataque de doble gasto, un atacante intenta gastar los mismos fondos dos veces mediante la transmisión simultánea de dos transacciones conflictivas. El consenso BFT lo impide al requerir que dos tercios de los validadores se pongan de acuerdo en una única orden de transacción antes de que esta se finalice. Una vez que una transacción se confirma en un sistema BFT, ninguna transacción competidora por los mismos fondos puede confirmarse sin infringir el umbral de dos tercios.
Ataques de Eclipse
En un ataque de eclipse, un atacante aísla un nodo específico rodeándolo de pares maliciosos, controlando así toda la información que recibe. Un nodo eclipsado con éxito puede recibir información falsa sobre el estado de la cadena de bloques. Los protocolos BFT se defienden contra esto exigiendo el acuerdo de una supermayoría del conjunto completo de validadores, no solo de los vecinos inmediatos del nodo. Incluso si un nodo es eclipsado, la gran mayoría honesta rechazará las transacciones que entren en conflicto con el estado real de la cadena.
Ataques de Sybil
Un ataque Sybil consiste en que un adversario crea múltiples identidades de nodos falsas para obtener una influencia desproporcionada sobre una red. En los sistemas BFT con permisos, los ataques Sybil se previenen exigiendo que los validadores estén formalmente registrados y autenticados. En los sistemas BFT de prueba de participación, como Ethereum, la resistencia a los ataques Sybil proviene del coste económico de la participación: crear múltiples validadores requiere apostar valor real por cada uno, lo que hace que los ataques Sybil sean costosos de ejecutar a gran escala.
El umbral de ataque del 33%
Los protocolos BFT clásicos solo ofrecen garantías de seguridad cuando menos de un tercio de los nodos son bizantinos. Si un atacante controla más de un tercio del conjunto de validadores (o más de un tercio del valor apostado en los sistemas PoS-BFT), la garantía de seguridad del protocolo se rompe. Esta es la limitación fundamental del consenso BFT. Esto no significa que un atacante con el 33 % de los nodos pueda robar fondos arbitrariamente, sino que potencialmente puede impedir la finalidad o, en el peor de los casos, provocar que los nodos honestos adopten estados conflictivos.
Por eso, el umbral del 33 % es un factor crítico para el modelo de seguridad de cualquier sistema basado en BFT. Protocolos como Casper de Ethereum añaden penalizaciones económicas al umbral de BFT: incluso si un atacante alcanza un tercio del ETH apostado, atacar con éxito la finalidad requeriría que se le confiscara la totalidad de su apuesta, lo que haría que el ataque fuera económicamente devastador para el atacante.
Manipulación de mensajes y ataques de repetición
Sin firmas criptográficasUn nodo bizantino podría interceptar y modificar mensajes entre nodos honestos, o reproducir mensajes válidos antiguos para confundir el proceso de consenso. Los protocolos BFT se defienden contra la manipulación de mensajes al exigir que cada mensaje de consenso esté firmado con la clave privada del remitente. Los números de secuencia y los identificadores de ronda integrados en los mensajes impiden que los mensajes válidos de una ronda se reproduzcan en una ronda posterior para causar confusión.
Obtén la tarjeta criptográfica UPay
Experimente lo mejor del pago en línea y transacciones de criptomonedas fluidas.
RegistrarseObtén la tarjeta criptográfica UPay
Experimente lo mejor del pago en línea y transacciones de criptomonedas fluidas.
RegistrarseVentajas de la tolerancia a fallos bizantinos en blockchain
Finalidad de transacción determinista e instantánea
Quizás la ventaja más importante del consenso BFT sobre los sistemas de prueba de trabajo sea su finalidad instantánea. En Bitcoin, una transacción nunca es matemáticamente definitiva; simplemente se vuelve cada vez más difícil de revertir a medida que se añaden más bloques. En un sistema BFT, una vez alcanzado el umbral de dos tercios en la fase de confirmación, la transacción se finaliza con certeza según los supuestos del protocolo. No es necesario esperar confirmaciones adicionales.
Esto es de vital importancia para las aplicaciones financieras. Las redes de pago no pueden funcionar de manera eficiente si cada transacción puede revertirse horas después. Las aplicaciones de finanzas descentralizadas requieren una finalidad fiable para liquidaciones, préstamos y liquidación de derivados. La comunicación entre cadenas mediante protocolos como IBC exige que una cadena demuestre a otra que una transacción específica es realmente definitiva.
Eficiencia energética
El consenso BFT clásico no requiere la enorme capacidad de cálculo que exige la prueba de trabajo de Bitcoin. Los validadores votan mediante firmas digitales, no resolviendo problemas computacionalmente intensivos. Esto hace que BFT sea mucho más eficiente energéticamente. La transición de Ethereum a PoS-BFT redujo su consumo energético en aproximadamente un 99.95 %, una reducción que fue posible precisamente porque sustituyó la prueba de trabajo por el sistema de votación de validadores BFT.
Resiliencia ante fallos de red y nodos maliciosos
Un protocolo BFT bien implementado sigue funcionando correctamente siempre que dos tercios de los nodos permanezcan conectados y en buen estado. Gestiona simultáneamente fallos por caída del sistema, particiones de red (temporales), nodos bizantinos y combinaciones de estos. Esta resiliencia es precisamente lo que necesitan las redes blockchain públicas: no pueden saber de antemano qué nodos fallarán o se comportarán de forma maliciosa, por lo que el protocolo de consenso debe gestionar los fallos arbitrarios de forma eficaz.
Alto rendimiento para sistemas con permisos
Los protocolos BFT en entornos con permisos, como Hyperledger Fabric, pueden alcanzar un rendimiento de transacciones muy elevado. Dado que el conjunto de validadores es fijo y conocido, la sobrecarga de comunicación es predecible y optimizable. Las implementaciones empresariales suelen alcanzar miles de transacciones por segundo con una finalización inferior a un segundo, un rendimiento imposible con la prueba de trabajo e incluso difícil de lograr para muchos sistemas de prueba de participación.
Seguridad contra fallas bizantinas y ataques coordinados
Los mecanismos BFT ofrecen una sólida protección contra ataques bizantinos coordinados. Un grupo de nodos maliciosos que actúan en connivencia y representan menos de un tercio del conjunto de validadores no puede interrumpir el consenso, independientemente de su estrategia. No pueden impedir que los nodos honestos lleguen a un acuerdo, no pueden inyectar transacciones falsas en el historial acordado ni pueden provocar que los nodos honestos adopten estados conflictivos. Esta sólida garantía de seguridad está demostrada matemáticamente, no solo observada empíricamente.
Desafíos y limitaciones de la tolerancia a fallos bizantinos
Restricciones de escalabilidad
El principal desafío de los algoritmos BFT clásicos radica en que la complejidad de la comunicación aumenta con el número de validadores. La complejidad de mensajes de PBFT, de orden O(n²), implica que añadir más validadores se vuelve rápidamente inviable. Una red con 100 validadores PBFT requiere hasta 10 000 mensajes por ronda de consenso. Con 1,000 validadores, esto se traduce en 1 000 000 de mensajes.
HotStuff y sus derivados abordaron este problema de manera drástica al reducir la complejidad a una complejidad lineal O(n) mediante la agregación de firmas umbral. Sin embargo, incluso la complejidad lineal tiene límites prácticos. La mayoría de las cadenas de bloques públicas actuales basadas en BFT mantienen conjuntos de validadores de entre cientos y unos pocos miles, en lugar de las decenas de miles que incluye la red de minería de Bitcoin.
Este límite de escalabilidad es la razón por la que el consenso BFT es común en las cadenas de bloques con permisos y en las redes de prueba de participación con conjuntos de validadores limitados, mientras que la prueba de trabajo sin permisos sigue siendo el mecanismo para las redes que priorizan la participación sin restricciones.
Dependencia de un conjunto de validadores conocidos
La mayoría de los protocolos BFT requieren un conjunto definido y autenticado de validadores. Esto funciona bien en entornos con permisos y en redes de prueba de participación, donde los validadores invierten capital para ganarse su lugar. Es mucho más difícil en entornos sin permisos, donde cualquiera puede participar sin registrarse. La prueba de trabajo de Bitcoin resolvió la versión sin permisos del problema de los generales bizantinos precisamente porque no requiere conocer de antemano quiénes son los participantes.
Sobrecarga de rendimiento
Lograr tolerancia a fallos bizantinos requiere una comunicación significativamente mayor entre nodos que los sistemas tolerantes a fallos no bizantinos. La votación multifase necesaria en los protocolos de tipo PBFT, la necesidad de recopilar y verificar un gran número de mensajes firmados criptográficamente y la sobrecarga de coordinación de los protocolos de cambio de vista (gestión de líderes fallidos) aumentan la latencia y el coste computacional. Para aplicaciones que requieren miles de transacciones por segundo con una latencia muy baja, estas sobrecargas exigen una ingeniería cuidadosa.
Complejidad de la correcta implementación
Las pruebas matemáticas que sustentan los algoritmos BFT son exactas: el protocolo es seguro y funcional si se implementa con precisión. Sin embargo, el software rara vez se implementa exactamente como se especifica. Las implementaciones reales contienen errores de concurrencia, casos límite en el manejo de la red, vulnerabilidades en la sincronización de mensajes y errores de implementación criptográfica que pueden violar las garantías del protocolo en la práctica, incluso cuando el diseño teórico es sólido. La interrupción de la cadena Cosmos Hub v17.1 ilustra esto: la garantía de seguridad fundamental de BFT se mantuvo, pero un error de software en el código circundante provocó una interrupción en la producción. Una implementación correcta de BFT requiere un rigor extremo en toda la pila de implementación, no solo en la lógica de la ronda de consenso.
Vulnerabilidad en el umbral del 33%
El requisito de una mayoría honesta del 33 % es tanto la fortaleza de BFT como su límite máximo. Mientras se cumpla esta premisa, el sistema es seguro. Sin embargo, si un atacante logra controlar un tercio o más del conjunto de validadores (o un tercio del valor apostado en sistemas PoS-BFT), las garantías de seguridad se rompen. En la práctica, esto requiere enormes recursos para las redes establecidas, pero las redes más pequeñas con un menor valor total apostado son más vulnerables a este ataque.
El futuro de la tolerancia a fallos bizantinos en blockchain
BFT post-cuántico
Los protocolos BFT actuales se basan en esquemas de firma criptográfica vulnerables a las computadoras cuánticas. Una computadora cuántica suficientemente potente podría romper la criptografía de clave pública que utilizan los protocolos BFT para autenticar los votos de los validadores. La investigación en BFT postcuántica explora activamente esquemas de firma resistentes a los ataques cuánticos, incluyendo criptografía basada en retículos y en funciones hash. Trezor Safe 7, una billetera de hardware, ya implementa criptografía postcuántica estandarizada por el NIST para la verificación del firmware, lo que indica que el ecosistema criptográfico en general avanza hacia la resistencia cuántica. Los protocolos BFT deberán seguir esta tendencia a medida que avance la computación cuántica.
Protocolos BFT asíncronos
El PBFT clásico y la mayoría de sus derivados se basan en supuestos de sincronía parcial: asumen que los retrasos de los mensajes están acotados, aunque se desconozca dicho límite. En condiciones completamente asíncronas (donde los retrasos de los mensajes pueden ser arbitrariamente largos), el teorema de imposibilidad FLP demuestra que el consenso determinista es imposible. Sin embargo, los protocolos BFT asíncronos aleatorios que utilizan funciones aleatorias verificables pueden lograr un consenso probabilístico incluso en condiciones de asincronía total. HoneyBadgerBFT y Dumbo son ejemplos de protocolos BFT asíncronos diseñados para funcionar de forma fiable incluso cuando las condiciones de la red están gravemente degradadas.
Escalabilidad mediante fragmentación y capa 2
Una estrategia prometedora para superar el límite de escalabilidad de BFT consiste en ejecutar múltiples instancias de BFT en paralelo mediante el sharding, donde la red se divide en subconjuntos (shards) que ejecutan su propio consenso BFT sobre una parte de las transacciones. La hoja de ruta de Ethereum incluye el sharding junto con la finalidad al estilo BFT. La arquitectura de cadena de aplicaciones de Cosmos es otra forma de escalabilidad horizontal: cada aplicación ejecuta su propia cadena CometBFT, distribuyendo la carga del consenso. Las soluciones de capa 2, como los rollups, añaden otra dimensión al agrupar las transacciones fuera de la cadena y utilizar cadenas protegidas por BFT para la liquidación final.
BFT en el Internet de las Cosas
Las redes IoT presentan un caso de uso convincente para el consenso BFT. Miles de millones de dispositivos IoT deben coordinarse y compartir datos de forma segura a través de redes distribuidas donde los dispositivos individuales pueden verse comprometidos físicamente, quedarse sin energía o ser manipulados deliberadamente. Investigaciones de 2025 muestran que los algoritmos basados en BFT proporcionan la baja latencia que requieren las aplicaciones IoT, aunque su alto costo computacional y su vulnerabilidad a ataques del 33 % hacen necesarias arquitecturas de red con permisos para las implementaciones de IoT. Internet de cosas Representa una de las áreas de mayor crecimiento para la investigación y el despliegue de BFT.
BFT en Finanzas Descentralizadas
Finanzas descentralizadas Las aplicaciones, que para 2025 habían acumulado más de 56.3 millones de dólares en valor total bloqueado, dependen fundamentalmente del consenso BFT para la fiabilidad de sus operaciones. Las liquidaciones, las fuentes de precios de los oráculos, las posiciones de préstamo y la liquidación de derivados requieren una finalidad rápida y fiable. Todos los principales protocolos DeFi se ejecutan en cadenas con consenso tipo BFT: Ethereum con Casper, las cadenas Cosmos con CometBFT y Stellar con FBA. A medida que las aplicaciones DeFi se vuelven más sofisticadas y gestionan más valor, la demanda de garantías BFT se vuelve más crítica, no menos.
Interoperabilidad entre sistemas BFT
Obtén la tarjeta criptográfica UPay
Experimente lo mejor del pago en línea y transacciones de criptomonedas fluidas.
RegistrarseEl futuro de la tecnología blockchain es cada vez más multicadena. Los activos y los mensajes se mueven entre Ethereum, las cadenas Cosmos, Stellar, las redes Hyperledger y otras. Interoperabilidad entre cadenas requiere que cada cadena verifique las pruebas de finalidad de las transacciones en otras cadenas. La finalidad instantánea de BFT hace esto drásticamente más simple: una prueba BFT finalizada es compacta y verificable, a diferencia de la finalidad probabilística de prueba de trabajoEsto requiere esperar numerosas confirmaciones antes de que cualquier operación entre cadenas sea segura. Tanto el protocolo IBC del ecosistema Cosmos como los diseños de puentes entre cadenas del ecosistema más amplio dependen de la finalidad de BFT para funcionar de forma segura. La investigación sobre interoperabilidad es una de las áreas más activas en el diseño de protocolos BFT.
Preguntas frecuentes
¿Qué es la tolerancia a fallas bizantinas en términos simples?
La tolerancia a fallos bizantinos es una propiedad de los sistemas distribuidos que les permite seguir funcionando correctamente incluso cuando algunos participantes actúan de forma deshonesta, cometen errores o intentan activamente perturbar el sistema. En blockchain, esto significa que la red continúa validando las transacciones correctamente aunque algunos nodos envíen información falsa o intenten manipular el proceso. La regla fundamental es que, siempre que más de dos tercios de los nodos sean honestos, el sistema llega a la conclusión correcta.
¿Por qué se denomina tolerancia a fallos "bizantina"?
El nombre proviene del Problema de los Generales Bizantinos, un experimento mental publicado por los informáticos Lamport, Shostak y Pease en 1982. En esta analogía, los generales bizantinos deben ponerse de acuerdo en un plan de batalla, aunque algunos sean traidores que envían mensajes falsos. El término «bizantino» alude al peor tipo de fallo: un comportamiento arbitrario y antagónico, no solo un choque o un silencio.
¿Cuántos nodos defectuosos puede tolerar un sistema BFT?
Los protocolos BFT clásicos, como PBFT, Tendermint y HotStuff, toleran como máximo un tercio de nodos bizantinos. Un sistema de n nodos puede gestionar f nodos bizantinos siempre que n sea al menos 3f + 1. Si más de un tercio de los nodos son defectuosos o maliciosos, las garantías de seguridad de estos protocolos se rompen. Se ha demostrado matemáticamente que este es el máximo teórico para BFT clásico bajo supuestos de red estándar.
¿Cuál es la diferencia entre PBFT y HotStuff?
Tanto PBFT como HotStuff son protocolos BFT basados en líderes que toleran hasta un tercio de nodos bizantinos y proporcionan finalidad instantánea. La principal diferencia radica en la complejidad de la comunicación. PBFT requiere O(n²) mensajes por ronda de consenso, lo que lo limita a conjuntos de validadores pequeños. HotStuff logra una comunicación lineal de O(n) mediante la agregación de votos en firmas umbral, lo que lo hace práctico para conjuntos de validadores mucho mayores. HotStuff utiliza tres viajes de ida y vuelta en lugar de los dos de PBFT, un pequeño aumento de latencia que se compensa con creces por la mejora en la escalabilidad.
¿Utiliza Ethereum tolerancia a fallos bizantinos?
Sí. El consenso de prueba de participación de Ethereum utiliza Casper FFG como mecanismo de finalidad, que es un mecanismo de votación al estilo BFT. Los validadores emiten votos sobre los bloques de punto de control, y cuando dos tercios del ETH apostado han votado a favor de un punto de control, este se finaliza. Ethereum añade seguridad económica además del umbral BFT clásico: los validadores que actúan de forma maliciosa son penalizados (pierden su ETH apostado), lo que hace que los ataques sean devastadores desde el punto de vista financiero y matemáticamente difíciles.
