---
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.
# 拜占庭容错：安全性、活性与法定人数
> 仅供协议分析教育参考。BFT 标签或法定人数阈值本身不能证明安全性、活性、正确执行、去中心化、最终性或资产安全。
## 直接答案
拜占庭容错（BFT）是某个明确分布式协议在明确故障模型和网络模型下的属性：即使部分参与者宕机、扣留消息、对不同对象发送矛盾消息，或以其他方式任意作恶，协议仍满足其声明的保证。BFT 不是单一算法，也不代表每次网络分区期间所有服务都保持可用。
必须区分各种保证。`safety`（安全性）表示诚实参与者不会决定相互冲突的值；`liveness`（活性）表示合格输入最终能够促成决定；`validity`（有效性）限制可以决定哪些值。通信或诚实投票权不足时，协议可以停下来以保全安全性。共识正确也不等于应用代码、交易有效性规则、跨链桥、密钥或治理正确。
对一类常见的、具有身份认证且部分同步的 BFT 协议，`n=3f+1` 个副本最多容忍 `f` 个拜占庭副本，提交证书使用 `q=2f+1` 票。熟悉的“故障少于三分之一”和“法定人数超过三分之二”来自这个模型。同步协议、随机化异步协议、崩溃容错协议、工作量证明链和其他 BFT 构造可能采用不同假设与阈值。
在按质押加权的系统中，阈值指协议定义的投票权，不一定是验证者数量、地址数量、人数或独立运营方数量。套用比例前，必须说明确切协议版本、权重快照、决定类型、网络假设、法定人数比较符（`>` 或 `>=`）及故障行为。
## 运作方式
1. **定义决定对象。** 确认节点是在排序交易、提交区块、最终确定检查点、选举领导者、接受状态转换还是选择分叉。这些不是可以互换的决定。
2. **说明系统与对手模型。** 记录成员资格、身份认证、权限变更、投票权重、自适应腐化、密钥泄露、矛盾投票、崩溃故障、消息丢失、审查、拒绝服务，以及故障是否可能相关。
3. **说明网络模型。** 区分同步、部分同步和异步。对部分同步模型，要指出哪些保证只在未知的全局稳定时间之后成立，以及超时如何调整。
4. **推导法定人数规则。** 使用协议的准确阈值、锁定与投票规则。在经典 `n=3f+1` 场景中，两个 `2f+1` 法定人数至少有 `f+1` 个副本重合；拜占庭副本最多为 `f` 时，交集必含诚实副本。
5. **追踪每个阶段和证书。** 核验提议、投票、锁定、视图或轮次变更、提交、分叉选择与恢复规则。只有节点验证高度、轮次、值、父级、域、成员时期和前序证书时，签名超级多数才有意义。
6. **分开验证安全性与活性。** 先证明在所有相关时刻排除了哪些冲突决定，再测试协议的通信与诚实参与假设恢复后是否重新推进。超时是调度工具，不能证明沉默节点有恶意。
7. **核验实现与运营。** 按照证明模型检查客户端多样性、密钥托管、签名器故障转移、防重放、状态同步、证据处理、成员变更、监控、应用确认政策和事故恢复。
FLP 结果指出：在完全异步模型中，只要可能有一个进程崩溃，确定性共识协议就不能保证终止。它没有说安全性不可能，也没有说分布式共识永远无法工作。部分同步、随机化、故障检测器、经济假设或较弱保证，分别通过改变特定不可能性条件来取得进展。
## 计算示例
### 1. 四个等权副本
设 `n=4`、`f=1`、`q=3`。任意两个三票集合至少重合 `3+3-4=2` 个副本。拜占庭副本最多一个，因此交集中至少有一个诚实副本。如果协议要求诚实节点不能在相关高度和轮次历史中为冲突值投票，就不可能同时形成两份冲突的提交证书。
若两个副本离线，只剩 `2` 票，无法形成 `q=3` 证书。这是活性故障，不会自动成为安全性故障：安全设计的协议会等待，而不是在本地降低阈值。
### 2. 七个等权副本
设 `n=7`、`f=2`、`q=5`。两个法定人数至少重合 `5+5-7=3=f+1` 个副本。由于拜占庭副本最多 `2` 个，交集必含诚实副本。两个拜占庭副本无法单独形成五票证书，但三个离线或扣票的副本会使可用票数只剩 `4`，足以阻止推进。
阈值算术是必要条件，却不是充分条件。如果诚实实现接受错误高度的投票、复用成员集合、违反锁定规则，或通过已泄露密钥签名，证明假设就与部署系统不再相符。
### 3. 加权投票权
假设验证者权重为 `40`、`30`、`20`、`10`，合计 `100`；证书要求严格超过 `2/3`，在这里实现为至少 `67`。`40+30=70` 的联盟可以形成证书；`30+20+10=60` 不行，尽管它包含四名验证者中的三名。若权重为 `40` 的验证者离线，只剩 `60`，最终性就会停顿。
任意两个至少为 `67` 权重的集合，至少重合 `67+67-100=34`。所以出现冲突证书意味着至少 `34` 权重同时参与两组投票，或者某项其他协议假设失效。这说明在部分协议中，只略高于三分之一的矛盾投票就可能破坏安全；“攻击必须有三分之二”不是普遍最低门槛。
### 4. 部分同步与超时
假设四个副本依次采用 `1 s`、`2 s`、`4 s`、`8 s` 的轮次超时。在未知稳定时间之前，消息可能每次都迟于当前超时到达，轮次因而不断变更而不作决定。网络稳定后，若延迟低于 `3 s`，则 `4 s` 或更后面的轮次可以让诚实提议者和法定人数有足够时间交换消息并推进，但仍须满足协议的其他假设。
这些数字只说明最终推进，并非通用超时公式。计时器过短会导致无谓的视图变更，过长则会拉长恢复延迟。安全性不能依赖在稳定前猜中正确的延迟上限。
## 风险与审查失误
### 模型与证明
- 只说“BFT”，却不说明协议、版本、决定对象、故障模型、网络模型、成员规则和阈值。
- 把 `n=3f+1` 或三分之一比例套到所有分布式账本，包括证明采用不同假设的协议。
- 把安全性、活性、有效性、可用性、一致性、最终性、分叉选择和交易正确性当作同义词。
- 宣称 FLP 证明共识不可能，却省略确定性、完全异步和保证终止这些条件。
- 协议按质押、委托权重、委员会、时期或其他资源计票时，仍按节点或地址数计数。
- 含糊取整“三分之二”，或忽略实现采用 `>`、`>=`、整数权重还是某个分母快照。
- 只检查法定人数大小，不检查交集、锁定、证书、视图变更、重新配置和状态转移。
- 未经证明就假设模型涵盖自适应腐化、密钥盗取、相关故障、拒绝服务或长程历史。
### 实现与运营
- 接受未绑定链、域、高度、轮次、值、父级、成员时期和消息类型的签名。
- 跨轮次、高度、分叉、网络、升级或验证者集合变更重放旧投票或证书。
- 允许双签、锁定回退、不安全的签名器故障转移，或两个活动副本共用一个验证者身份。
- 把超时到期当作恶意证明，并仅凭本地时钟作出影响安全性的决定。
- 忽略共同客户端、云服务、地区、网络、硬件、密钥管理或运营方造成的相关故障。
- 误以为罚没能够阻止故障、恢复活性、撤销已最终执行的应用操作，或赔偿所有受影响用户。
- 只测试正常运行，不测试分区、消息延迟与重排、矛盾投票、提议者故障、重启和成员变更。
### 应用与治理
- 未进行确定性执行和状态转换验证，就把共识提交值当成有效应用状态。
- 在达到应用所需的准确最终性条件前记入充值、铸造跨链资产或结算交易。
- 假设密钥泄露、软件故障或治理干预后的社会不可逆性与协议最终性完全相同。
- 因区块仍为其他用户最终确定，就忽略审查和交易纳入延迟。
- 从 BFT 标签或宣传的验证者数量推断去中心化、资产安全、代币价值或法律可执行性。
## 常见误区
- **BFT 表示网络永不停机。** 许多 BFT 协议在故障过多或网络分区时会主动牺牲活性以保全安全性。
- **诚实参与者超过 51% 总是足够。** 阈值取决于协议；经典部分同步 BFT 通常需要相关投票权超过三分之二才能推进。
- **攻击者总要有三分之二才能破坏安全。** 三分之二可以独自形成证书，但在常见法定人数设计中，两份冲突的超级多数证书可能只暴露略高于三分之一的矛盾投票。
- **增加验证者地址必然提高容错。** 共同所有权、委托权重、客户端、基础设施、密钥和故障域决定独立容错能力。
- **罚没就是 BFT 证明。** 罚没是部分 PoS 系统的经济应对；安全性来自协议规则与假设，惩罚也不能撤销外部后果。
## 相关主题
- [拜占庭将军问题](/zh-cn/crypto/byzantine-generals-problem/)
- [共识机制](/zh-cn/crypto/consensus-mechanism/)
- [最终性](/zh-cn/crypto/finality/)
- [权益证明](/zh-cn/crypto/proof-of-stake/)
- [验证者](/zh-cn/crypto/validator/)
## 资料来源
- [The Byzantine Generals Problem](https://lamport.azurewebsites.net/pubs/byz.pdf) - ACM Transactions on Programming Languages and Systems（访问日期：2026-08-18）
- [Impossibility of Distributed Consensus with One Faulty Process](https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf) - Journal of the ACM（访问日期：2026-08-18）
- [Consensus in the Presence of Partial Synchrony](https://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf) - Journal of the ACM（访问日期：2026-08-18）
- [Practical Byzantine Fault Tolerance](https://pmg.csail.mit.edu/papers/osdi99.pdf) - USENIX OSDI（访问日期：2026-08-18）
- [CometBFT Consensus Algorithm](https://docs.cometbft.com/v0.38/spec/consensus/consensus) - CometBFT（访问日期：2026-08-18）
- [HotStuff: BFT Consensus with Linearity and Responsiveness](https://arxiv.org/abs/1803.05069) - arXiv（访问日期：2026-08-18）
- [Gasper](https://ethereum.org/developers/docs/consensus-mechanisms/pos/gasper/) - Ethereum.org（访问日期：2026-08-18）
- [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST（访问日期：2026-08-18）
Source: https://wiki.fcontext.com/zh-cn/crypto/byzantine-fault-tolerance/index.mdx