¿Qué es el problema de los generales bizantinos? Cómo la cadena de bloques resuelve la confianza en sistemas distribuidos
2026/04/03 23:44:00
El problema de los generales bizantinos es un concepto fundamental en la teoría de sistemas distribuidos que describe el desafío de alcanzar un consenso confiable entre participantes que no pueden confiar plenamente unos en otros ni en los canales de comunicación entre ellos. Descripto formalmente por primera vez por los científicos de la computación Leslie Lamport, Robert Shostak y Marshall Pease en un artículo de 1982, el problema captura precisamente el tipo de fallo de coordinación que cualquier red descentralizada debe superar para funcionar de manera confiable. Su solución —o, más precisamente, los enfoques desarrollados para gestionarlo— forma la base teórica de cómo la tecnología blockchain logra un consenso sin confianza.
Este artículo explica el problema de los generales bizantinos en términos concretos, examina cómo los mecanismos de consenso BFT lo abordan y conecta estos principios con el modelo de confianza de la cadena de bloques que sustenta los activos con los que los operadores interactúan en los mercados de criptomonedas hoy en día.
Principales conclusiones
-
El problema de los generales bizantinos describe la dificultad de lograr un acuerdo confiable entre participantes distribuidos cuando algunos pueden actuar de forma maliciosa o fallar de manera impredecible.
-
Un sistema se considera tolerante a fallas bizantinas (BFT) si puede alcanzar un consenso correcto incluso cuando una fracción definida de sus participantes se comportan de manera deshonesta o envían información contradictoria.
-
El mecanismo de consenso de prueba de trabajo de bitcoin fue la primera solución práctica al problema de los generales bizantinos en una red abierta y sin permiso sin un coordinador de confianza.
-
Diferentes mecanismos de consenso de cadena de bloques — incluyendo proof-of-work, proof-of-stake y protocolos BFT clásicos — representan diferentes compromisos en cómo logran la tolerancia a fallos bizantinos.
-
El umbral de seguridad en la mayoría de los sistemas BFT requiere que menos de un tercio de los participantes actúen de manera maliciosa; en las redes de prueba de trabajo, el umbral equivalente es el 51% de la tasa de hash total.
-
Comprender el consenso BFT ayuda a los operadores a interpretar las suposiciones de seguridad de la red y evaluar los vectores de ataque realistas que enfrentan los activos de la cadena de bloques que poseen o negocian.
El problema de los generales bizantinos: El experimento mental original
El problema de los generales bizantinos se presenta como una alegoría militar. Imagina un grupo de generales del ejército bizantino, cada uno al mando de una división separada, rodeando una ciudad enemiga. Para tener éxito, deben coordinar un ataque simultáneo o una retirada simultánea: cualquiera de los dos resultados es aceptable, pero una mezcla de divisiones que atacan y se retiran resultará en derrota. Los generales solo pueden comunicarse mediante mensajeros, y algunos de los generales pueden ser traidores que enviarán mensajes diferentes a distintos destinatarios en un intento de crear confusión y hacer fallar el plan coordinado.
El problema plantea: ¿pueden los generales leales alcanzar un acuerdo confiable sobre un único plan de acción, incluso en presencia de traidores que envían información contradictoria? Y si es así, ¿cuál es el número mínimo de generales leales requerido en relación con el número de traidores para garantizarlo?
Lamport, Shostak y Pease demostraron en su artículo de 1982 que el problema es soluble solo si más de dos tercios de los generales son leales. En otras palabras, un sistema puede tolerar hasta un tercio de sus participantes actuando de forma maliciosa o enviando información defectuosa, pero no más. Si los traidores constituyen un tercio o más del total, ningún algoritmo puede garantizar que los generales leales lleguen a la misma decisión.
La traducción directa a la computación distribuida es sencilla: reemplace "generales" por "nodos en una red", "mensajeros" por "canales de comunicación de red" y "traidores" por "nodos defectuosos o maliciosos". Cualquier sistema distribuido —ya sea un clúster de base de datos, una red de pagos o una cadena de bloques— enfrenta un problema de coordinación equivalente cada vez que no puede asumir que todos los participantes son honestos y que todos los mensajes se entregan fielmente. Los operadores en KuCoin interactúan con la salida práctica de este problema cada vez que se confirma una transacción: la red ha alcanzado un consenso tolerante a fallas bizantinas que la transacción es válida.
Por qué el problema es difícil: Los dos modos de fallo
El problema de los generales bizantinos es distinto de los problemas de tolerancia a fallas más simples porque abarca dos categorías separadas de fallas que deben manejarse ambas.
Fallos de caída
Un fallo por colapso ocurre cuando un nodo simplemente deja de responder — se desconecta, pierde energía o experimenta un error de software. Este es el modo de fallo más simple. Un sistema que puede tolerar fallos por colapso solo necesita asegurar que suficientes nodos permanezcan en línea para alcanzar un cuórum. Los sistemas distribuidos clásicos, como clústeres de bases de datos, manejan fallos por colapso mediante votación por mayoría: siempre que más de la mitad de los nodos estén disponibles y respondiendo, el sistema puede avanzar.
Fallos bizantinos
Una falla bizantina es fundamentalmente más difícil. Ocurre cuando un nodo permanece en línea pero se comporta incorrectamente — ya sea porque ha sido comprometido por un atacante o porque experimenta una falla de software sutil que lo lleva a enviar mensajes inconsistentes a diferentes destinatarios. Un nodo que experimenta una falla bizantina podría enviar un voto "sí" a algunos pares y un voto "no" a otros, o podría retener selectivamente mensajes para retrasar el consenso. A diferencia de un nodo caído, un nodo con falla bizantina participa activamente en el protocolo mientras lo socava.
La distinción es extremadamente importante para el diseño de la cadena de bloques. En una red abierta y sin permisos donde cualquiera puede ejecutar un nodo, no se puede hacer cumplir la suposición de que los participantes son honestos. Por lo tanto, cualquier mecanismo de consenso debe diseñarse para alcanzar decisiones correctas incluso en presencia de participantes con fallos bizantinos, no solo de los que se han caído.
Cómo Bitcoin resolvió el problema de los generales bizantinos
El documento blanco de Satoshi Nakamoto de 2008 no utilizó explícitamente el término "Problema de los Generales Bizantinos", pero el protocolo que describió fue una solución directa y novedosa a este problema en un entorno abierto y sin permiso, algo que la investigación previa sobre BFT no había logrado.
La idea clave en el diseño de prueba de trabajo de Bitcoin es que reemplaza la votación basada en identidad (donde cada participante obtiene un voto) con la votación basada en recursos (donde cada unidad de trabajo computacional obtiene un voto). Este cambio resuelve una debilidad crítica en los protocolos BFT clásicos: en una red abierta, un atacante puede crear un número ilimitado de identidades falsas (un ataque Sybil) y usarlas para anular a los participantes honestos. Al vincular el poder de voto al trabajo computacional físico —que requiere recursos reales—, Bitcoin hace que la fabricación de identidades sea económicamente costosa en lugar de trivialmente barata.
La regla de consenso es sencilla: la cadena válida es la que tiene la mayor cantidad de prueba de trabajo acumulada. Cada bloque añadido a la cadena representa una unidad de esfuerzo computacional; la cadena más larga representa el mayor esfuerzo total realizado por los participantes honestos de la red. Para reescribir la historia —reemplazar un bloque confirmado con uno alternativo— un atacante necesitaría volver a hacer no solo el trabajo de ese bloque, sino también el trabajo de todos los bloques posteriores, y al mismo tiempo superar el trabajo continuo de la red honesta. Esto requiere controlar más del 50% de la tasa total de hash de la red, lo que equivale a la prueba de trabajo al umbral de tolerancia a fallas bizantinas.
La elegancia de esta solución es que funciona sin que ningún participante conozca la identidad de los demás, sin ningún coordinador central y sin suponer que los participantes son honestos más allá de la suposición racional de que minar honestamente es más rentable que atacar una red cuyo valor depende de su integridad.
Consenso BFT en redes de Proof-of-Stake y permitidas
El proof-of-work es una solución al problema de los generales bizantinos, pero no es la única. Diferentes arquitecturas de cadena de bloques implementan el consenso tolerante a fallos bizantinos a través de distintos mecanismos, cada uno con propiedades de seguridad y características de rendimiento distintas.
Protocolos BFT clásicos
Los algoritmos BFT clásicos, derivados de la investigación académica en sistemas distribuidos, logran consenso a través de múltiples rondas de intercambio de mensajes entre un conjunto conocido y fijo de validadores. Cada validador transmite su voto, recopila votos de otros y llega a una decisión cuando observa una supermayoría (típicamente dos tercios más uno) de validadores de acuerdo en el mismo valor. Estos protocolos pueden lograr finalidad rápida: una transacción se confirma en segundos en lugar de minutos, porque la confirmación proviene de un voto directo en lugar de una prueba de trabajo acumulada.
La compensación es que los protocolos BFT clásicos requieren un conjunto de validadores conocido y acotado. No funcionan en redes completamente abiertas donde cualquiera puede unirse sin permiso, porque un atacante podría saturar la red con validadores bizantinos. Se utilizan principalmente en redes de cadena de bloques con permisos y en diseños de prueba de stake, donde los validadores se identifican por su capital apostado.
Prueba de participación BFT
Los mecanismos de consenso de prueba de participación abordan el problema del ataque Sybil de manera diferente a la prueba de trabajo: en lugar de vincular el poder de voto al trabajo computacional, lo vinculan al valor económico apostado. Un validador debe bloquear una cantidad significativa del activo nativo de la red como fianza. Si el validador se comporta de manera deshonesta —por ejemplo, firmando bloques conflictivos— el protocolo puede destruir automáticamente una parte de la fianza apostada (una sanción conocida como slashing).
Este desincentivo económico reemplaza el costo de recursos físicos de la prueba de trabajo como mecanismo que hace costoso el comportamiento bizantino. El umbral de seguridad permanece similar: siempre que menos de un tercio del valor stakes esté controlado por validadores bizantinos, la red puede alcanzar un consenso correcto. Los validadores y sus saldos stakes son visibles en la cadena, lo que significa que su participación en el consenso y cualquier evento de slashing son verificables públicamente. Los operadores que monitorean activos de prueba de stake en KuCoin's live market pairs pueden rastrear las tasas de participación de los validadores y las proporciones de stake como indicadores de la salud de la seguridad de la red.
La relación entre la tolerancia BFT y la seguridad de la red
El umbral de tolerancia a fallos bizantinos — la fracción máxima de participantes deshonestos que una red puede tolerar — es la expresión más directa del modelo de seguridad de una cadena de bloques. Comprenderlo ayuda a evaluar la superficie de ataque realista de cualquier red.
Para los protocolos BFT clásicos y la mayoría de los diseños de prueba de stake, el umbral es un tercio: la red permanece segura siempre que menos de un tercio de los validadores (por peso de voto o valor stakeado) sean bizantinos. Si un atacante controla un tercio o más, puede impedir que la red alcance la finalidad —un fallo de disponibilidad— o, en algunos diseños, causar que confirme transacciones conflictivas —un fallo de seguridad.
Para las redes de prueba de trabajo, el umbral equivalente es la mitad: un atacante necesita controlar más del 50% de la tasa de hash total para ejecutar un ataque de reorganización sostenida. Este umbral de ataque del 51% es más alto en términos absolutos que el umbral de un tercio de BFT, pero el modelo de seguridad de la prueba de trabajo se basa en el costo de adquirir esa tasa de hash, no en la suposición de que los validadores son conocidos y identificables.
Varios factores afectan la robustez práctica de estos umbrales en redes reales:
-
Tasa de hash o concentración de stake: si la minería o el stake están altamente concentrados entre un pequeño número de entidades, el costo efectivo de alcanzar el umbral de ataque es menor de lo que sugiere el porcentaje bruto.
-
Tamaño de la red: conjuntos de validadores más grandes o pools de minería distribuidos entre más entidades independientes aumentan la dificultad práctica de coordinar un ataque bizantino.
-
Incentivos económicos: atacar exitosamente una red generalmente destruye el valor del activo atacado, lo que hace que los atacantes racionales sean poco probables de ejecutar ataques incluso cuando son técnicamente factibles.
Un análisis detallado de cómo estos factores de seguridad se manifiestan en diferentes mecanismos de consenso se cubre en el KuCoin research and education blog, donde se publican regularmente desgloses técnicos de modelos de seguridad de red.
Qué significa el consenso BFT para los operadores
El problema de los generales bizantinos y sus soluciones tienen implicaciones prácticas directas para los operadores que evalúan e interactúan con activos basados en cadena de bloques.
Finalidad de la transacción
Diferentes implementaciones de BFT producen distintas garantías de finalidad. En las redes de prueba de trabajo, la finalidad es probabilística: una transacción se vuelve progresivamente más segura a medida que se añaden más bloques encima de ella, pero nunca se garantiza matemáticamente que sea irreversible. En BFT clásico y muchos diseños de prueba de stake, la finalidad es económica y casi inmediata: una vez que una supermayoría de validadores ha firmado un bloque, revertirlo requeriría destruir una parte significativa de la fianza stakeada — un resultado prohibitivamente costoso.
Para los operadores, el tipo de finalidad afecta el riesgo de liquidación. Al retirar activos de una red para liquidar una operación, el número de confirmaciones requeridas antes de que la parte receptora considere la transacción final depende del mecanismo de consenso de la red y su costo de ataque asociado.
Riesgo de ataque del 51% en redes más pequeñas
Los activos en redes más pequeñas de prueba de trabajo enfrentan un riesgo significativamente mayor de ataque del 51% porque su tasa de hash total es lo suficientemente baja como para que adquirir la mayoría sea económicamente factible. Varias redes más pequeñas de prueba de trabajo han experimentado ataques del 51% documentados, resultando en transacciones de doble gasto. Para los operadores, esto representa un riesgo concreto de contraparte al mantener u operar activos en redes con bajo gasto total en seguridad. Monitorear la tasa de hash y las métricas de seguridad de la red de activos de prueba de trabajo más pequeños —observable a través de datos en la cadena— es parte de evaluar el perfil de riesgo de esas posiciones.
Concentración de validadores en Proof-of-Stake
En las redes de prueba de participación, la concentración de stake entre un pequeño número de validadores plantea preguntas sobre la tolerancia práctica a fallos bizantinos de la red, independientemente de su umbral teórico. Cuando un alto porcentaje de activos apostados está controlado por un pequeño número de entidades, la coordinación necesaria para alcanzar el umbral de ataque se vuelve más factible. Monitorear la distribución de validadores y la descentralización del stake en activos de prueba de participación proporciona información sobre cuán cerca se encuentra el margen de seguridad de la red del umbral de BFT. Los operadores que desean mantenerse informados sobre desarrollos de seguridad a nivel de red y actualizaciones de protocolo para activos listados en la plataforma pueden seguir KuCoin's official announcements.
Conclusión
El problema de los generales bizantinos, descrito formalmente en 1982 y resuelto prácticamente para redes abiertas mediante el diseño de prueba de trabajo de Bitcoin en 2009, define el desafío central de lograr consenso confiable en sistemas distribuidos donde no se puede asumir que los participantes sean honestos. El consenso BFT —ya sea logrado mediante prueba de trabajo, prueba de stake o protocolos BFT clásicos— es lo que permite que las redes de cadena de bloques funcionen como libros mayores confiables sin coordinadores centrales. El mecanismo específico que una red utiliza para lograr tolerancia a fallos bizantinos determina sus garantías de finalidad, su umbral de seguridad y su vulnerabilidad a ataques coordinados. Para los operadores, comprender estos fundamentos proporciona una base más sólida para evaluar las suposiciones de seguridad incrustadas en cada activo de cadena de bloques que poseen.
Crea una cuenta gratuita en KuCoin para descubrir las próximas gemas cripto y operar más de 1.000 activos digitales globales hoy. Create Now!
Preguntas frecuentes
¿Qué es el problema de los generales bizantinos en términos sencillos?
El problema de los generales bizantinos describe el desafío de alcanzar un acuerdo confiable entre un grupo de participantes cuando algunos pueden ser deshonestos o enviar información contradictoria. En redes distribuidas, representa la necesidad de lograr un consenso correcto incluso cuando algunos nodos son defectuosos o maliciosos, sin ninguna autoridad central para resolver desacuerdos.
¿Cómo resuelve la cadena de bloques el problema de los generales bizantinos?
Bitcoin lo resolvió reemplazando la votación basada en identidad con la votación basada en recursos mediante proof-of-work. Cada unidad de trabajo computacional cuenta como un voto, lo que hace prohibitivamente costoso fabricar votos mediante identidades falsas. Las redes de proof-of-stake lo resuelven vinculando el poder de voto al valor económico del stake, con penalizaciones de slashing que hacen que el comportamiento bizantino sea costoso.
¿Qué significa tolerante a fallos bizantinos?
Un sistema tolerante a fallas bizantinas (BFT) es aquel que puede alcanzar un consenso correcto incluso cuando una fracción definida de sus participantes actúan de manera deshonesta o envían mensajes contradictorios. La mayoría de los protocolos BFT toleran hasta un tercio de los participantes que se comportan de forma maliciosa; las redes de prueba de trabajo toleran hasta un 49% de la potencia de hash controlada por mineros deshonestos.
¿Qué es un ataque del 51% y cómo se relaciona con BFT?
Un ataque del 51% es el equivalente en proof-of-work de exceder el umbral de tolerancia a fallos bizantinos. Si un atacante controla más del 50% de la tasa total de hash de una red, puede reescribir el historial de transacciones recientes y potencialmente ejecutar transacciones de doble gasto. Es la manifestación más directa del fallo de tolerancia a fallos bizantinos en una cadena de bloques proof-of-work.
¿Por qué importa el umbral de un tercio en el consenso BFT?
El umbral de un tercio es el resultado matemático de la demostración del problema original de los generales bizantinos: un sistema puede garantizar un consenso correcto solo si menos de un tercio de los participantes son bizantinos. Si un tercio o más son deshonestos, los participantes honestos no pueden distinguir entre mensajes contradictorios con suficiente confiabilidad para llegar a un acuerdo seguro. Este umbral determina directamente el modelo de seguridad de la mayoría de los protocolos de cadena de bloques de prueba de stake y BFT clásicos.
Descargo de responsabilidad: La información de esta página puede haberse obtenido de terceros y no necesariamente refleja las opiniones o puntos de vista de KuCoin. Este contenido se proporciona únicamente con fines informativos generales, sin ninguna representación o garantía de ningún tipo, ni se considerará como asesoramiento financiero o de inversión. KuCoin no será responsable por errores u omisiones, ni por ningún resultado derivado del uso de esta información. Las inversiones en Activos digitales pueden ser arriesgadas. Evalúe cuidadosamente los riesgos de un producto y su tolerancia al riesgo según sus propias circunstancias financieras. Para más información, consulte nuestras Condiciones de uso y Divulgación de riesgos.
Aviso: Esta página fue traducida utilizando tecnología de IA (impulsada por GPT) para tu conveniencia. Para obtener la información más precisa, consulta la versión original en inglés.