---
title: "Problema de los generales bizantinos: acuerdo con mensajes incompatibles"
description: "El problema de los generales bizantinos pregunta cómo pueden acordar los participantes honestos cuando los defectuosos envían información incompatible. Hay que separar tarea, canales, autenticación, límite de fallos, cota, algoritmo y despliegue."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Problema de los generales bizantinos: acuerdo con mensajes incompatibles
> Material educativo de análisis de protocolos. Resolver un modelo de acuerdo bizantino no demuestra que una red desplegada sea segura, viva, correcta, descentralizada, final ni segura para los activos.
## Respuesta directa
El problema de los generales bizantinos pregunta cómo participantes no defectuosos que se comunican mediante mensajes pueden tomar una decisión coherente cuando algunos actúan arbitrariamente, incluso enviando afirmaciones distintas a receptores diferentes. La historia militar es una analogía de la consistencia interactiva en sistemas distribuidos, no un hecho histórico ni un algoritmo concreto de consenso de blockchain.
En la formulación de comandante y tenientes, `IC1` exige que todos los tenientes leales obedezcan la misma orden, mientras `IC2` exige que obedezcan la orden del comandante si este es leal. El acuerdo solo no basta: elegir siempre RETIRADA produce acuerdo, pero vulnera una orden válida de ATAQUE dada por un comandante leal.
En el modelo de «mensajes orales» del artículo, con un máximo de `m` traidores solo hay solución cuando `n>3m`, equivalente para participantes enteros a `n>=3m+1`. El modelo supone que los mensajes enviados por leales se entregan correctamente, el receptor conoce al remitente y puede detectar la ausencia de un mensaje esperado. «Oral» significa que un contenido no autenticado puede falsificarse como relato de otro participante; no que un mensajero desaparezca para siempre sin detección.
El modelo de «mensajes firmados» añade firmas no falsificables y verificables públicamente, y cambia el resultado de resiliencia. No vuelve verdadero el contenido, no garantiza entrega ni terminación totalmente asíncrona, no protege claves robadas ni demuestra la seguridad de un protocolo moderno. El problema bizantino, el de los dos generales o ataque coordinado, FLP, BFT, prueba de trabajo y prueba de participación son modelos o construcciones relacionados pero distintos.
## Cómo analizarlo
1. **Definir la tarea de acuerdo.** Indicar participantes, entradas, salidas y propiedades exactas de acuerdo, validez y terminación. En la formulación del comandante, escribir `IC1` e `IC2` en vez de decir solo «alcanzar consenso».
2. **Definir identidades y canales.** Indicar si los mensajes punto a punto están autenticados, se entregan, ordenan, protegen de repetición y atribuyen; si se detecta la omisión; y si la difusión es primitiva o envíos repetidos.
3. **Definir el tiempo.** Separar sincronía con demora acotada, sincronía parcial tras un instante desconocido y asincronía total. No añadir mensajeros perdidos a un modelo y conservar un teorema de otro.
4. **Definir el presupuesto de fallos.** Registrar participantes totales `n`, máximo bizantino `m`, corrupción estática o adaptativa y si incluye omisión, equivocación, colusión, robo de claves o canales defectuosos.
5. **Seguir la información recursivamente.** Para cada leal, enumerar afirmaciones directas y retransmitidas, rutas de remitentes, valores por ausencia y desempates deterministas; comparar qué ejecuciones distinguen dos vistas locales.
6. **Comprobar juntos teorema y algoritmo.** Ajustar cotas y suficiencia al modelo oral o firmado, conectividad y presupuesto exactos. Una desigualdad no es una implementación ni una prueba.
7. **Mapear al despliegue.** Verificar el `OM(m)`, `SM(m)` u otro mecanismo real, dominios de mensaje, rondas, bloqueos, certificados, cambios de miembros, plazos, clientes, finalidad y política de confirmación.
La técnica clave es la indistinguibilidad. Un participante leal solo ve sus mensajes locales; si dos ejecuciones le parecen iguales pero la validez exige decisiones distintas, ninguna regla determinista puede acertar siempre. Los protocolos agregan suficientes participantes independientes, pruebas autenticadas, supuestos temporales, azar u otra estructura para distinguir las ejecuciones necesarias o cambiar la garantía.
## Ejemplos calculados
### 1. Por qué tres generales con mensajes orales no toleran un traidor
Sean `n=3` y `m=1`. La condición `n>3m` se convierte en `3>3`, que es falsa. Supongamos que el comandante A dice `ATTACK` a B y `RETREAT` a C. B no distingue si A es traidor y envió órdenes incompatibles o si C es traidor y miente sobre lo dicho por A; C afronta la incertidumbre simétrica.
Cualquier regla determinista que preserve la orden de A en ejecuciones donde A es leal puede obligar a B y C a decidir distinto cuando A es traidor. Retransmitir no crea una cuarta fuente independiente, por lo que no se garantizan a la vez `IC1` e `IC2`.
### 2. Cuatro generales con mensajes orales y un traidor
En `OM(1)`, `n=4` y `m=1`. El comandante envía una orden a tres tenientes; cada uno retransmite su valor a los otros dos; cada leal aplica la misma mayoría y valor predeterminado. Si el comandante es leal y envía `v`, un leal ve `v`, `v` y un posible `x` del traidor, así que elige `v`.
Si el comandante es el único traidor, los tres tenientes son leales y retransmiten exactamente lo recibido. Reconstruyen así el mismo conjunto de afirmaciones del comandante y aplican la misma regla. Quizá no recuperen su «intención real», pero cumplen el acuerdo.
### 3. Cota general de los mensajes orales
Con `n=7` y `m=2`, `7>6` se cumple, de modo que la cantidad satisface la condición y la construcción recursiva tolera hasta dos traidores bajo sus demás supuestos. Para `n=6`, `6>6` es falso. Para `n=10` y `m=3`, `10>9` se cumple. Pasar la desigualdad es necesario; también hacen falta rondas, retransmisión, mayoría, valores predeterminados y canales correctos.
### 4. Qué cambian las firmas
En un ejemplo de tres generales `SM(1)`, el comandante traidor firma `ATTACK` para B y `RETREAT` para C. Los tenientes leales reenvían ambas órdenes, por lo que ambos obtienen `{ATTACK, RETREAT}` y aplican el mismo valor especificado, por ejemplo `RETREAT`. La equivocación del comandante queda atribuida.
Las firmas impiden falsificar o alterar sin detección la orden de un participante leal bajo el modelo. No revelan cuál orden refleja la «intención real» del traidor, no garantizan entrega puntual ni impiden que quien controla una clave legítima firme ambas.
## Riesgos y fallos de revisión
### Problema y modelo
- Repetir la alegoría sin condiciones precisas de acuerdo, validez y terminación.
- Tratar el problema como sitio histórico, algoritmo único o sinónimo de blockchain.
- Confundirlo con los dos generales, centrado en conocimiento común por canal no fiable.
- Añadir pérdida permanente indetectable y citar un teorema oral que la excluye.
- Aplicar `n>3m` a todo protocolo autenticado, asíncrono, ponderado, sin permisos o basado en recursos.
- Igualar caída, omisión, equivocación, cómputo arbitrario, canal defectuoso y clave comprometida.
- Suponer que participantes equivalen a entidades independientes, participación, potencia o peso de comité.
- Omitir la diferencia entre comandante leal y traidor en la condición de validez.
### Algoritmo e implementación
- Mirar solo la mayoría final sin seguir rutas recursivas y cada vista local.
- Usar valores por ausencia, desempates, instantáneas de miembros u órdenes distintos entre implementaciones.
- Aceptar mensajes sin vincular protocolo, cadena, tarea, altura, ronda, valor, remitente y época.
- Repetir o empalmar mensajes entre ejecuciones, rondas, bifurcaciones, redes o cambios de miembros.
- Suponer que las firmas prueban verdad, frescura, contexto de autorización, entrega, disponibilidad o custodia honesta.
- Citar `OM(m)` o `SM(m)` sin implementar rondas, retransmisión, verificación y conectividad requeridas.
- Probar una sola posición de traidor y no comandante, teniente, colusión, omisión y equivocación.
### Despliegue e interpretación
- Afirmar que un consenso «resuelve Bizancio» sin supuestos exactos de seguridad, vivacidad y red.
- Tratar el acuerdo sobre bytes como prueba de ejecución o hecho externo correcto.
- Ignorar fallos correlacionados por clientes, operadores, nubes, claves o gobernanza comunes.
- Acreditar depósitos, emitir activos puente o liquidar acciones irreversibles antes de la finalidad requerida.
- Inferir descentralización, seguridad de activos, verdad jurídica o valor del token de una etiqueta de tolerancia.
## Errores comunes
- **El problema es solo un ataque del 51%.** Trata conducta arbitraria e incompatible bajo un modelo de acuerdo; las mayorías de recursos pertenecen a protocolos concretos.
- **Una mayoría siempre lo resuelve.** En el modelo oral clásico, tolerar `m` traidores exige más del triple de participantes totales, no solo un honesto más.
- **Las firmas digitales demuestran que el mensaje es verdadero.** Autentican una clave y protegen integridad; una clave maliciosa o comprometida firma contenido falso o incompatible.
- **El resultado oral original ya cubre entrega no fiable.** Incluye supuestos explícitos de entrega, identidad y omisión detectable; otros modelos necesitan otros resultados.
- **El acuerdo significa conocer la realidad.** Sin validación aparte, los nodos leales pueden acordar una salida inválida o un dato externo erróneo.
## Temas relacionados
- [Tolerancia a fallos bizantinos](/es/crypto/byzantine-fault-tolerance/)
- [Mecanismo de consenso](/es/crypto/consensus-mechanism/)
- [Finalidad](/es/crypto/finality/)
## Fuentes
- [The Byzantine Generals Problem](https://lamport.azurewebsites.net/pubs/byz.pdf) - ACM Transactions on Programming Languages and Systems (consulta: 2026-08-19)
- [Reaching Agreement in the Presence of Faults](https://lamport.azurewebsites.net/pubs/reaching.pdf) - Journal of the ACM (consulta: 2026-08-19)
- [Impossibility of Distributed Consensus with One Faulty Process](https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf) - Journal of the ACM (consulta: 2026-08-19)
- [Consensus in the Presence of Partial Synchrony](https://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf) - Journal of the ACM (consulta: 2026-08-19)
- [Practical Byzantine Fault Tolerance](https://pmg.csail.mit.edu/papers/osdi99.pdf) - USENIX OSDI (consulta: 2026-08-19)
- [CometBFT Consensus Algorithm](https://docs.cometbft.com/v0.38/spec/consensus/consensus) - CometBFT (consulta: 2026-08-19)
- [HotStuff: BFT Consensus with Linearity and Responsiveness](https://arxiv.org/abs/1803.05069) - arXiv (consulta: 2026-08-19)
- [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST (consulta: 2026-08-19)
Source: https://wiki.fcontext.com/es/crypto/byzantine-generals-problem/index.mdx