拜占庭故障不只是节点宕机，还包括节点向不同参与者发送互相矛盾的信息。PBFT 通过有认证的消息、多轮确认和副本状态机来容忍这类故障；理解它必须先说明模型，不能只记住“多数投票”。

这是一份概念学习笔记，依据 Castro 与 Liskov 的 1999 年论文相应章节，不包含实现、完整证明或性能实验。

将军故事说明什么，不能说明什么

假设多位将军只能通过消息商量同一个行动，叛徒却分别发送“进攻”和“撤退”。问题不在于各自能不能数出一个多数，而在于诚实参与者看到的信息不同，能否仍遵循同一规则达成一致。

故事本身不能推出通用容错比例。消息能否认证、网络延迟是否有界、故障类型和要求的性质都会改变结论。

PBFT 系统模型 §2 允许消息丢失、延迟、重复和乱序，使用密码机制约束伪造，并对攻击者长期阻断正确节点作出限制。认证只能说明消息来自谁，不能阻止故障节点用自己的身份撒谎。

3f+1 是总副本数，不是诚实节点数

论文简化算法以总副本数 n = 3f + 1 容忍至多 f 个故障副本。例如容忍一个故障时，总共四个副本，最多一个故障，而不是“四个诚实副本再加一个坏副本”。

以四个副本、集合大小三为例，两个这样的集合至少重叠两个成员；最多一个故障，因此交集至少包含一个正确成员。这是理解交集约束的算例，不是仅凭这个算式就证明整个协议安全。

正常流程里的三种条件不能混数

一个视图中有主副本与备份。主副本为请求安排序号，副本按确定性状态机执行同一顺序。依据 原论文 §4，正常流程可分为：

环节主要作用与条件
pre-prepare主副本提出视图、序号与请求摘要，备份检查是否可接受
prepare副本交换对该提议的准备信息；prepared 包含请求、匹配的 pre-prepare 与来自不同备份的 2f 条匹配 prepare
commit已 prepared 的副本发送 commit；本地提交还要求来自不同副本的 2f+1 条匹配 commit
客户端接受结果等待 f+1 个不同副本、相同请求与结果的有效匹配回复

f=1 时，prepared 不是笼统收三条同类 prepare，而是匹配提议再加两条备份 prepare；本地提交需要三条匹配 commit。计数时可包含协议允许计入的本机消息，不能把同一副本重复发送当作多个身份。

执行还要满足较小序号请求的顺序要求。pre-prepare 不是“主节点一说就所有副本同意”，commit 也不是简单重复 prepare 的名字。

视图切换与检查点，不是三个阶段之外的小装饰

主副本无法推进时，视图切换用协议规定的证据和选择规则继承必要历史，不能只凭超时随机换个节点就继续。检查点用于证明状态进度、回收旧日志，并配合水位线限制处理范围。

安全性关注正确副本不执行冲突历史，活性关注最终能否推进；永久网络阻断下不能承诺一定完成。三阶段计数只是阅读起点，不足以替代视图切换、认证、持久化和恢复的完整设计。

正常路径中副本间通信随规模增加而显著增长，但固定 TPS、“任意删除某阶段必然产生某一种故障”或某产品必然采用 PBFT，都需要独立证据，不从概念图直接推出。