Problema de los generales bizantinos: 4 nodos, 1 traidor

Cuatro nodos bastan para sobrevivir a un traidor; siete hacen falta para sobrevivir a dos

Esa proporción, n ≥ 3f + 1, es la regla que separa a un sistema distribuido que aguanta de uno que se parte en dos. Viene de un problema que Leslie Lamport y sus colegas formalizaron en 1982: el problema de los generales bizantinos, la pregunta de cómo un grupo de máquinas llega a un acuerdo cuando algunas pueden estar rotas o mintiendo.

Para un founder, la relevancia es directa: cada vez que prometes que tu plataforma «no tiene punto único de fallo», estás haciendo una afirmación sobre este problema, la hayas estudiado o no. Y la mayoría de las arquitecturas que se venden como tolerantes a fallos no lo son.

¿Qué es el problema de los generales bizantinos?

Tres ejércitos rodean una ciudad. Si atacan juntos, ganan; si se retiran juntos, sobreviven; si se dividen, los que atacan son aniquilados. Su única forma de comunicarse son jinetes que cruzan territorio enemigo.

La explicación visual publicada esta semana plantea el escenario como dos puzzles interactivos y ahí está el primer mérito: separa dos problemas que casi siempre se mezclan en las conversaciones de sobremesa sobre blockchain.

• El problema de los dos generales: todos son honestos, pero los mensajes pueden perderse. ¿Pueden dos partes estar seguras de que acordaron algo?
• El problema de los generales bizantinos: todos los mensajes llegan, pero alguien miente. ¿Pueden los leales actuar como uno solo?

El primer caso tiene una respuesta incómoda: no. Quien envía el último mensaje nunca sabe si llegó, así que la certeza exigiría una cadena infinita de confirmaciones. Fue el primer problema de comunicación entre computadoras que se demostró irresoluble.

Y sin embargo internet funciona. TCP no resuelve el problema: lo esquiva. Reduce la probabilidad de fallo hasta que se vuelve muy poco probable, pero nunca imposible. Esa es una lección de producto más que de ingeniería: a veces la respuesta correcta no es eliminar el riesgo, sino hacerlo estadísticamente irrelevante.

La trampa de la simetría: por qué dos leales no vencen a un mentiroso

Con tres generales y un traidor, los dos leales no pueden ponerse de acuerdo. La explicación lo demuestra poniéndote en los botas de un teniente: recibes dos mensajes que no coinciden y no tienes forma de saber si el traidor es el comandante o el otro teniente. Los dos mundos posibles te entregan exactamente los mismos mensajes, palabra por palabra.

El otro teniente está en la situación espejo. Cada uno hace lo correcto con la información que tiene, y esa simetría es justo lo que el traidor explota para dividirlos. Ningún reglamento acordado de antemano los salva: con un traidor entre tres, siempre se rompe alguno de los dos objetivos.

Con cuatro generales, en cambio, funciona. Cada teniente recibe las tres versiones de la orden y se queda con la mayoría. Un teniente mentiroso queda superado por dos copias verdaderas. Un comandante mentiroso puede mandar órdenes distintas, pero como los demás retransmiten con honestidad, todos los leales terminan con los mismos tres valores y llegan a la misma mayoría.

De ahí sale la regla general:

• 1 traidor → hacen falta 4 generales
• 2 traidores → hacen falta 7 generales
• 10 computadoras → como máximo 3 traidores (con 4, solo 6 de 10 serían leales, y no alcanza)

La intuición de «mayoría simple» es la que falla. Un traidor no emite un voto honesto: puede decirle cosas distintas a cada persona, y por eso hace falta más de dos tercios de nodos leales.

¿Por qué esto dejó de ser teoría de laboratorio?

El problema nació de investigación financiada por NASA para hacer computadoras lo bastante confiables como para volar aviones comerciales. Hoy tiene dos frentes muy activos.

Agentes de IA. Un estudio de Andy Hall, Dan Thompson, Alexander Fouirnaies y Sandy Handan-Nader, publicado el 29 de septiembre de 2026 y difundido por Unite.AI, encontró que en sistemas multi-agente los modelos posteriores siguen una conclusión errónea temprana incluso cuando su propia información apunta a la respuesta correcta. En el experimento, las señales privadas eran informativas el 70% de las veces y la condición de estrés hizo que las primeras cuatro fueran incorrectas. La mayoría de las pruebas usó Claude Haiku 4.5, con replicación en Sonnet 4.6, Opus 4.6 y GPT-5 mini.

La conclusión práctica: cinco agentes que repiten la misma conclusión no equivalen a cinco verificaciones. Si todos leyeron el mismo resumen equivocado, tienes un solo punto de evidencia con cinco ecos. Hackernoon lo describe como el «radio de explosión semántico» de un sistema multi-agente, y cita investigación de AAAI 2026 que aplica precisamente la mirada de tolerancia a fallos bizantinos a la confiabilidad de agentes.

Puentes blockchain. Hackernoon documenta el error más caro del sector: confundir un multisig k-de-n con un protocolo BFT real. El puente de Ronin exigía 5 firmas de 9 validadores y perdió US$600 millones; la red de guardianes de Wormhole pide 13 de 19. Un multisig no distingue un firmante honesto de uno comprometido: solo cuenta. No tiene cambio de líder, ni detección de comportamiento inconsistente, ni forma de notar que una firma viene de una clave que ya no debería existir.

Criptografía cuántica. Según Scienmag, un equipo de la University of Science and Technology of China publicó en Quantum Information Processing un protocolo de acuerdo bizantino con firmas cuánticas que tolera un número arbitrario de nodos maliciosos, apoyándose solo en claves de distribución cuántica. Lo simularon en una red de cinco nodos con twin-field QKD, una variante ya demostrada en tramos de fibra de hasta 830 kilómetros.

Las tres salidas reales (y lo que cuesta cada una)

Nadie ha derrotado la imposibilidad. Lo que se hace es cambiar las reglas del juego:

• Sellos infalsificables. Cada orden lleva una firma digital que nadie puede replicar. Con eso, hasta tres generales bastan, porque un comandante de dos caras deja su firma en dos órdenes distintas. El precio: cada nodo necesita su clave y todo mensaje tiene que llegar.
• Relojes y plazos. Si asumes que los mensajes llegan dentro de un tiempo conocido, un jinete ausente se nota. Así funciona PBFT (Practical Byzantine Fault Tolerance, 1999), que necesita 3f + 1 máquinas. El precio: si los retrasos pueden ser ilimitados, ningún método puede prometer que terminará, ni siquiera con una sola máquina caída. Eso se demostró en 1985.
• Aceptar casi certeza. Los votos se cuentan por poder de cómputo en lugar de por identidad, como en el proof of work de Bitcoin. Un atacante con el 10% del poder de cómputo tiene alrededor de un 0.09% de probabilidad de revertir un pago enterrado 5 bloques. Más bloques, menos probabilidad, nunca cero.

Esa última cifra es la que más se malinterpreta en el marketing cripto. Bitcoin no resolvió el problema: cambió la pregunta de «certeza» a «probabilidad abrumadora».

¿Qué significa esto para tu startup?

1. Cuenta tus nodos antes de prometer tolerancia a fallos. Si tu arquitectura tiene 3 réplicas y asumes que aguanta un nodo comprometido o mintiendo, no aguanta: necesitas 4. Si el riesgo es que dos nodos fallen a la vez, necesitas 7. Revisa tu documentación técnica y ajusta la promesa al número real.

2. Distingue multisig de BFT en tu stack de custodia. Si tu puente, tu wallet multisig o tu custodia institucional usa k-de-n validadores, no tienes BFT: tienes un umbral de firmas. Pregunta explícitamente por rotación y expiración automática de claves. En Ronin, cuatro de las cinco claves comprometidas pertenecían al mismo operador, y la quinta venía de una lista de firma antigua que nunca se revocó.

3. En sistemas multi-agente, mide corroboración, no cantidad. Antes de sumar un agente más a tu pipeline, define si aporta una observación independiente o solo repite la anterior. Separa en tu workspace la observación cruda (el output de la herramienta, sin tocar) de la interpretación del agente. Y no dejes que el permiso de ejecutar cambios se derive del consenso: un equipo de agentes puede equivocarse sin tener autorización para tocar producción.

4. Cuidado con la palabra «imposible». Si tu pitch dice que algo es «matemáticamente imposible de revertir», un comprador técnico va a preguntar bajo qué supuestos. La respuesta honesta —»muy improbable bajo estas condiciones»— vende mejor que una promesa que no se sostiene.

Conclusión

El problema de los generales bizantinos no se resuelve: se negocia. Si los mensajes pueden perderse, dos partes nunca tendrán certeza absoluta de haber acordado. Si los mensajes llegan pero alguien miente, el acuerdo solo está garantizado con más de dos tercios de nodos leales. Todo lo demás —firmas, plazos, proof of work, firmas cuánticas— son formas de cambiar los supuestos, no de romper la regla.

Para quien construye, la utilidad no está en la teoría sino en la pregunta que obliga a hacer: ¿cuántos de mis componentes pueden fallar o mentir a la vez, y qué pasa con mi producto cuando lo hagan?

Fuentes

• The Byzantine Generals Problem: A visual explanation (fuente original)
• Quantum Keys Push Byzantine Agreement Toward Unbreakable Network Consensus – Scienmag
• What Bridge Multisigs Get Wrong About Byzantine Fault Tolerance – Hackernoon
• When AI Agents Follow the Crowd: The Hidden Risk in Multi-Agent Consensus – Unite.AI
• Semantic Blast Radius: How Errors Propagate Through Multi-Agent Systems – Hackernoon

Artículos relacionados:

OpenAI bajo subpoena de fiscales: 5 claves para founders de IA Claude Code analiza MRI: founder usa IA para segunda opinión médica WhatsApp prohíbe chatbots generales: Nuevo golpe a la automatización IA multiagente: el problema de sistemas distribuidos Impact Hub Ciudad de México y Foro Valparaíso presentan resultados de «Emprender con Discapacidad”