---
title: "拜占庭将军问题：在矛盾消息下达成一致"
description: "拜占庭将军问题追问：故障参与者可能发送矛盾信息时，诚实参与者怎样达成一致。必须分别分析一致任务、信道与认证假设、故障上限、下界、算法和实际部署。"
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.

# 拜占庭将军问题：在矛盾消息下达成一致

> 仅供协议分析教育参考。解决一种拜占庭一致模型，不能证明实际网络安全、有活性、实现正确、去中心化、具备最终性或能够保障资产。

<a id="answer"></a>

## 直接答案

拜占庭将军问题追问：只能通过消息通信的无故障参与者，怎样在部分参与者可任意行动、甚至向不同接收者发送矛盾说法时作出一致决定。军事故事是分布式系统“交互一致性”的类比，不是历史事件，也不是某一种区块链共识算法。

在“司令—副官”表述中，`IC1` 要求所有忠诚副官执行同一命令，`IC2` 要求司令忠诚时，每名忠诚副官执行司令的命令。只达成一致还不够：永远选择撤退的规则虽能一致，却会违背忠诚司令发出的有效进攻命令。

在论文的“口头消息”模型中，若叛徒最多为 `m`，仅当 `n>3m` 时问题才可解；参与者数量为整数时等价于 `n>=3m+1`。该模型假定忠诚者发出的消息能被正确送达、接收者知道发送者是谁，且能够发现预期消息缺失。“口头”表示未经认证的内容可被伪造成其他参与者的转述，并不等于信使可以永远消失且无人察觉。

论文的“签名消息”模型加入不可伪造、任何人可验证的签名，因而改变容错结论。它不会使签名内容变真，不会保证送达、解决完全异步终止、保护被盗密钥，或证明现代协议安全。拜占庭将军问题、两军问题或协调攻击问题、FLP、BFT 协议、工作量证明和权益证明彼此相关，却是不同模型或构造。

<a id="mechanism"></a>

## 分析方法

1. **定义一致任务。** 说明参与者、输入、输出，以及准确的一致性、有效性和终止属性。对司令模型，应明确写出 `IC1` 与 `IC2`，而不是只说“达成共识”。
2. **定义身份与信道。** 说明点对点消息是否认证、可靠送达、有序、防重放和可归责；消息缺失能否发现；广播是基本原语还是靠逐个发送实现。
3. **定义时序。** 区分延迟有上界的同步、未知稳定时间后的部分同步与完全异步。不能给一个模型加入消失的信使，却沿用为另一个模型证明的定理。
4. **定义故障预算。** 记录参与者总数 `n`、拜占庭参与者上限 `m`、腐化是静态还是自适应，以及故障是否包括遗漏、矛盾消息、串谋、密钥盗取或信道故障。
5. **递归追踪信息。** 对每名忠诚参与者列出直接说法和转述说法，包括发送者路径、缺失消息默认值和确定性平局规则；比较两名忠诚者从本地视图能区分哪些执行。
6. **同时核对定理与算法。** 把下界和充分性对应到准确的口头或签名模型、连通性与故障预算。一个阈值不等式既不是实现，也不是证明。
7. **映射到实际部署。** 核验部署协议的 `OM(m)`、`SM(m)` 或其他机制，以及消息域、轮次、锁定、证书、成员变更、超时、客户端行为、最终性规则与应用确认政策。

关键证明技术是不可区分性。忠诚参与者只能看到自己的本地消息；若两次执行在它看来完全相同，却因有效性要求不同决定，那么任何确定性规则都无法始终正确选择。协议通过增加足够多的独立参与者、认证证据、时序假设、随机性或其他结构，使必要的执行变得可区分，或者改变所承诺的保证。

<a id="example"></a>

## 计算示例

### 1. 三名口头消息将军为何不能容忍一名叛徒

设 `n=3`、`m=1`。必要条件 `n>3m` 变为 `3>3`，不成立。假设司令 A 告诉副官 B `ATTACK`，却告诉副官 C `RETREAT`。B 无法判断是 A 作为叛徒发送矛盾命令，还是 C 作为叛徒谎报 A 的说法；C 面临对称的不确定性。

任何能在相应“忠诚 A”执行中保留忠诚司令命令的确定性选择，都可能迫使 B 和 C 在“叛徒 A”执行中作出不同决定。转发消息不会创造第四个独立来源，因此无法同时保证 `IC1` 与 `IC2`。

### 2. 四名口头消息将军与一名叛徒

在 `OM(1)` 中，`n=4`、`m=1`。司令向三名副官发送命令；每名副官把收到的值转发给另外两名；每名忠诚副官采用同一个多数规则与默认值。若司令忠诚并发送 `v`，忠诚副官看到的值可为 `v`、`v` 和叛徒可能发送的 `x`，所以选择 `v`。

若司令是唯一叛徒，三名副官全都忠诚，并如实转发各自收到的内容。因此三者重建出同一组“司令向各副官发送的说法”，并采用相同确定性规则。他们未必找回司令的“真实意图”，但能满足一致性。

### 3. 口头消息的一般下界

当 `n=7`、`m=2` 时，`7>6` 成立，所以参与者数量满足前提；在其他假设也成立时，递归口头消息构造最多容忍两名叛徒。对 `n=6`，`6>6` 不成立。对 `n=10`、`m=3`，`10>9` 成立。通过不等式只是必要条件，仍须正确实现轮次、转发、多数、默认值和信道。

### 4. 签名改变了什么

在三名将军的 `SM(1)` 示例中，叛徒司令为发给 B 的 `ATTACK` 和发给 C 的 `RETREAT` 分别签名。忠诚副官转发两份签名命令，所以双方都得到同一个集合 `{ATTACK, RETREAT}`，并采用同一个规定默认值，例如 `RETREAT`。司令发送矛盾命令的行为可以归责。

在该模型下，签名防止忠诚参与者的命令被伪造或被无痕修改。它不会揭示叛徒两份命令中的哪一份代表“真实意图”，不会保证及时送达，也不能阻止控制合法私钥的攻击者同时签署两份内容。

<a id="risks"></a>

## 风险与审查失误

### 问题与模型

- 只复述寓言，不给出准确的一致性、有效性与终止条件。
- 把拜占庭将军问题当作历史围城、单一算法或区块链的同义词。
- 与两军问题混淆；后者关注不可靠信道上的共同知识。
- 加入无法发现的永久消息丢失，却引用口头消息假设排除此情形的定理。
- 把 `n>3m` 套到所有认证、异步、加权、无许可或按资源竞争的协议。
- 把崩溃、遗漏、矛盾消息、任意计算、信道故障和密钥泄露视为同一种故障。
- 假设参与者数量等于独立实体、质押、算力或委员会权重。
- 在有效性条件中遗漏忠诚司令与叛徒司令的区别。

### 算法与实现

- 只看最终多数，不递归追踪发送者路径及每名忠诚参与者的本地视图。
- 各实现采用不同的缺失消息默认值、平局规则、成员快照或消息顺序。
- 接受未绑定协议、链、任务、高度、轮次、值、发送者和成员时期的消息。
- 跨执行、轮次、分叉、网络或成员变更重放、拼接消息。
- 假设签名能够证明真实、新鲜、授权语境、送达、可用或密钥被诚实保管。
- 引用 `OM(m)` 或 `SM(m)`，却未实现所需轮次、转发、验证与连通性。
- 只测试一种叛徒位置，不测试司令、副官、串谋、遗漏和矛盾消息情形。

### 部署与解释

- 宣称某共识协议“解决了拜占庭问题”，却不说明准确的安全、活性与网络假设。
- 把对字节达成一致当作应用执行或链外事实正确的证明。
- 忽略共同客户端、运营方、云服务、密钥系统或治理造成的相关故障。
- 在达到所需最终性条件前记入充值、铸造跨链资产或结算不可逆操作。
- 从容错标签推断去中心化、资产安全、法律事实或代币价值。

<a id="misconceptions"></a>

## 常见误区

- **这个问题就是 51% 攻击。** 它研究明确一致模型下的任意与矛盾行为；资源多数攻击属于特定协议。
- **多数总能解决问题。** 在经典口头消息模型中，容忍 `m` 名叛徒要求参与者总数超过其三倍，不只是诚实者比叛徒多一名。
- **数字签名证明消息是真的。** 签名可认证密钥并保护完整性；恶意或已泄露的密钥仍能签署虚假、矛盾内容。
- **原始口头消息结果已经涵盖不可靠送达。** 该结果包含明确的送达、发送者身份和可发现遗漏假设；其他时序与信道模型需要其他结论。
- **达成一致表示系统获知了现实真相。** 除非另有验证规则，忠诚节点也可能对无效应用输出或错误外部数据达成一致。

<a id="related"></a>

## 相关主题

- [拜占庭容错](/zh-cn/crypto/byzantine-fault-tolerance/)
- [共识机制](/zh-cn/crypto/consensus-mechanism/)
- [最终性](/zh-cn/crypto/finality/)

<a id="sources"></a>

## 资料来源

- [The Byzantine Generals Problem](https://lamport.azurewebsites.net/pubs/byz.pdf) - ACM Transactions on Programming Languages and Systems（访问日期：2026-08-19）
- [Reaching Agreement in the Presence of Faults](https://lamport.azurewebsites.net/pubs/reaching.pdf) - Journal of the ACM（访问日期：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（访问日期：2026-08-19）
- [Consensus in the Presence of Partial Synchrony](https://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf) - Journal of the ACM（访问日期：2026-08-19）
- [Practical Byzantine Fault Tolerance](https://pmg.csail.mit.edu/papers/osdi99.pdf) - USENIX OSDI（访问日期：2026-08-19）
- [CometBFT Consensus Algorithm](https://docs.cometbft.com/v0.38/spec/consensus/consensus) - CometBFT（访问日期：2026-08-19）
- [HotStuff: BFT Consensus with Linearity and Responsiveness](https://arxiv.org/abs/1803.05069) - arXiv（访问日期：2026-08-19）
- [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST（访问日期：2026-08-19）

Source: https://wiki.fcontext.com/zh-cn/crypto/byzantine-generals-problem/index.mdx