先分清：掉线崩溃还是恶意消息
谈区块链容错算法，先写清故障假设，而不是先比“哪个算法更先进”。Hyperledger Fabric文档把排序服务实现分成Raft与BFT两类：Raft被明确写成崩溃容错（CFT）排序服务，基于etcd中的Raft协议实现；BFT则写明除崩溃外还可承受一部分节点恶意行为。
两类假设回答的问题不同。CFT关心节点宕机、进程退出或网络暂时失联后，集群能否继续就日志顺序达成一致；BFT还要把“故意发送矛盾消息”纳入模型。把崩溃容错材料直接当成拜占庭问题的解法，会跨过文档边界。
Fabric里Raft如何组织确认
Fabric对Raft的说明采用“leader and follower”模型：通道的consenter集合会选出一个leader，由它提议日志，followers复制。文档把quorum写成对给定consenter集合的多数派确认门槛；日志条目是排序工作的基本单位，各节点有限状态机用来保持日志序列一致。
生产网络说明还强调：Raft允许指定哪些排序节点加入哪个通道，便于组织控制参与共识的节点集合。文档同时提醒，类似Solo，Raft也可能在向客户端确认接收后仍因leader崩溃等原因丢失交易——这是实现边界，不能写成“确认即最终上链完成”。
Raft论文怎么定义多数派可用性
Raft论文把共识概括为多台服务器就某个值达成一致，且一旦决定即不可回退；典型算法在任意多数服务器可用时继续推进。例如5台服务器的集群允许2台失效仍可运行，若失效更多则停止推进，但不会返回错误结果。
论文还把Raft与Paxos在容错与性能上视为同级，并强调其分解为可理解的子问题。用来对照Fabric时，只需抓住：多数派可用性描述的是崩溃容错进度条件，并不自动覆盖恶意消息假设。
阅读与归档边界
读Fabric排序服务材料时应核对：当前讨论的是Raft还是BFT、consenter集合与quorum如何定义、以及确认接收与最终提交的区别。读Raft论文摘要时应核对：它给出的是多数派可用性，而非拜占庭容错证明。
本文不复现攻击路径、不给出主网参数调优建议，也不把任一实现写成投资或安全评级。归档时记录文档页范围（Ordering Service / Raft论文PDF）与抓取时间，并注明搜索摘要不作事实依据。