HotStuff 与 BFT

• Jolteon 简化 HotStuff 的响应与提交规则
• 减少 active view change 的延迟
• 与 HotStuff 的关系及在 Aptos 中的应用

Jolteon 是 HotStuff 的一种简化扩展，旨在降低 HotStuff 在 view change（视图切换）时的延迟与复杂度。原版 HotStuff 用三阶段（2-chain/3-chain）与复杂的 view change 回调，Jolteon 改进了提交规则与响应机制，使确认提交更快、视图切换更顺畅，同时保持线性通信复杂度。Jolteon 被用于 Aptos 等区块链的共识实现中，以提升延迟与吞吐表现。

Jolteon 的改进聚焦于"更快确认 + 更平滑的视图切换"，是 HotStuff 在真实区块链部署中的工程优化。它保留了 HotStuff 的线性通信优点，但简化了确认与切换逻辑。

• CFT 假设节点只能崩溃（fail-stop）
• BFT 假设节点可任意/恶意行为
• 两者在容错节点数、通信复杂度上的差异

CFT（Crash Fault Tolerance）假设节点只会崩溃（停止工作），不会故意发送错误消息，代表协议如 Raft、Paxos，需要 2f+1 节点容忍 f 个故障。BFT（Byzantine Fault Tolerance）假设节点可能任意行为甚至恶意（撒谎、伪造、合谋），代表协议如 PBFT，需要 3f+1 节点容忍 f 个故障。二者的边界在于"故障模型"，即系统对节点行为的假设：CFT 信任节点诚实、BFT 假设节点可能作恶。BFT 因需要对抗恶意行为，在通信复杂度与节点冗余上成本更高，通常用于区块链等信任边界弱的场景。

故障模型决定了协议的容错能力与设计：CFT 安全性依赖"多数派诚实"，BFT 安全性依赖"不少于 2/3 诚实"（3f+1）。跨过这条边界，协议的复杂性、节点数与通信成本都显著上升。

• Tendermint 基于 PBFT 思想的三轮投票
• 验证者质押与恶意惩罚
• 出块与确定性终结

Tendermint Core 是基于 BFT 的区块链共识引擎，核心机制类似 PBFT：通过多轮投票（propose、pre-vote、pre-commit）在验证者之间达成一致，区块一旦获得 2/3 以上诚实节点的三阶段确认即确定性终结（无分叉）。Tendermint 引入验证者（validator）与质押（stake）机制，验证者按质押比例参与共识，恶意或故障验证者会被惩罚（slashing）。它采用"确定性最终性"而非概率最终性，出块延迟低，适合需要即时确认的区块链。

Tendermint 把 BFT 共识与区块链的"出块 + 验证者 + 惩罚"结合，实现确定性最终性与低延迟。它是 Cosmos 生态的共识基础，也是 PBFT 思想在区块链的典型应用。

• 每阶段产生一个 quorum certificate（QC）
• 三阶段形成 3-chain 才提交
• 与 PBFT 三阶段的对偶关系

HotStuff 采用三阶段投票：Prepare（提议）、Pre-commit（预提交）、Commit（提交）。每个阶段由 leader 广播提议，各节点投票，多数派投票形成对应 quorum certificate（QC）。一个区块需要连续三轮 QC（即 3-chain：parent's QC 与当前 QC 形成两链、再与下一轮形成三链）才真正提交。三阶段与 PBFT 的 Pre-prepare/Prepare/Commit 对应，但 HotStuff 通过"每轮只与 leader 通信"实现线性通信复杂度。三阶段确保在 view change 中已提交的区块被保留。

三阶段投票的目的是在 view change 时保证"已提交区块不被回退"。3-chain 的规则连接了提案与 QC，使任何已提交的区块都获得足够多的证书支撑，从而在拜占庭环境下保持安全。

• 3-chain 的构成与提交条件
• 2-chain 不足以在 view change 中保证安全
• 与锁定（locked）机制的关系

HotStuff 中，一个区块 B 需要其 QC 与后续两轮产生的 QC 形成"3-chain"（即 B 的 QC 被 block B+1 引用，B+1 的 QC 被 B+2 引用，形成三连证书）才能提交。2-chain 只形成两轮证书，不足以在 view change（leader 切换）时保证"已提交区块不被覆盖"：因为拜占庭节点可能利用 2-chain 的跨度制造分歧。3-chain 通过更深的证书链确保任何已提交区块都有足够多的诚实证书支撑，从而在视图切换后仍被保留。3-chain 是安全性（view change 下块不丢失）与活性（能够推进）之间的平衡。

3-chain 的"深度"是 HotStuff 安全性的关键：它使提交的置信度跨越 view change 的窗口。2-chain 只够"预提交"，需再一轮确认形成 3-chain 才真正提交，这保证了在 leader 切换时已提交块不会被回退。

• Aptos 用 Jolteon 扩展的 HotStuff
• Sui 用基于 DAG 的 Narwhal/Bullshark 与 HotStuff 的取舍
• 高吞吐与低延迟的实证

Aptos 采用基于 HotStuff 的 Jolteon 共识，通过线性通信与优化视图切换实现高吞吐、低延迟的确定性出块。Sui 早期也基于 HotStuff（其前身 Diem 的共识），但后续演进采用基于 DAG（有向无环图）的 Narwhal-Bullshark 共识，以更高并行度提升吞吐。两者都体现了 HotStuff 家族"线性通信复杂度 + 高吞吐"的优点，而 Sui 的 DAG 化进一步突破单 leader 的吞吐瓶颈。这些应用验证了 HotStuff 在开源区块链领域的工程可行性。

HotStuff 的线性通信与确定性终结使其非常适合区块链；Aptos 直接采用其 Jolteon 变体，Sui 则在吞吐上向 DAG 演进。这展示了 HotStuff 家族的工程演化路径。

• 基于历史表现选择 leader
• 防止恶意/低效 leader 频繁作恶
• 提升活性与公平性

HotStuff 的 leader reputation 机制根据验证者历史表现（如成功出块、诚实参与、是否触发 view change）评估其信誉，从而优先选择信誉高的节点作为 leader。这能降低恶意或低效 leader 频繁作恶的概率，减少不必要的 view change，提升共识的活性与公平性。信誉机制可变相惩罚行为不端的验证者，使系统在有拜占庭节点的环境中更稳健。

leader reputation 是 HotStuff 家族在活性与公平性上的增强：通过"让好 leader 更可能当选"来降低恶意 leader 的干扰，是对基础 HotStuff 的工程优化，用于提升区块链的运行稳定性。

• 不同区块的阶段在时间上重叠
• 每轮一个区块，三阶段交错
• 提升吞吐、降低延迟

HotStuff 的 pipelining 让不同区块的三阶段在时间上交错执行：当区块 B 在进行 Commit 阶段时，区块 B+1 已在 Pre-commit、B+2 已在 Prepare，形成流水线。这样每个轮次只推进一个区块，但多轮区块的阶段在时间上重叠，使 leader 每轮只需一次广播即可推进，大幅提升吞吐并降低消息延迟。pipelining 也简化了协议：每个区块只需"一轮广播 + 一轮投票"，多个区块的证书在流水线上累积。

pipelining 是 HotStuff 线性通信与高吞吐的关键——它把"多轮串行"变为"流水线并行"，使吞吐不再受每轮 RTT 限制。这也是 HotStuff 能超越 PBFT O(n²) 的重要原因。

• 每轮仅 leader 与各节点通信（O(n)）
• PBFT 每阶段全互联投票（O(n²)）
• 线性通信对可扩展性的意义

HotStuff 的通信复杂度为 O(n)：每个轮次中，leader 向所有节点广播提议，各节点只向 leader 回复投票（通过签名聚合），因此每轮消息数正比于节点数 n。PBFT 每阶段需要所有节点全互联通信（每个节点向所有其他节点发送消息），复杂度为 O(n²)。线性通信使 HotStuff 在节点数多时仍可扩展，吞吐不因"全互联"而急剧下降，这是 HotStuff 相比 PBFT 的重大工程优势，也是其被区块链采用的原因。

通信复杂度从 O(n²) 降到 O(n)，使共识扩展到更多节点成为可能。HotStuff 通过"只与 leader 通信 + 签名聚合"实现线性通信，同时以 3-chain 保持安全性，是复杂度与安全的平衡。

• primary 故障时触发 view change
• 新 primary 收集新视图的稳定检查点
• 保证已提交消息不丢失

PBFT 中，当 primary（主节点）故障或超时未响应时，其余节点发起 view change：递增 view 编号，向新 primary 发送包含自己已确认消息集合的 view-change 消息。新 primary 收集 2f+1 个 view-change 消息后，确定新视图下应继续的序列，广播 new-view 消息，使节点在新视图下继续共识。view change 通过"传递已确认的稳定检查点/消息"保证已提交的操作不被丢失，同时剔除故障 primary。这是 PBFT 在 primary 故障时保持活性与安全的关键机制。

view change 是 PBFT 活性与安全性的结合点：新 primary 必须继承已提交状态，避免故障 primary 导致的安全缺口。其复杂度较高，HotStuff 通过"线性通信 + 链式确认"简化了视图切换。

• PBFT 全互联投票的 O(n²) 开销
• HotStuff 用 leader 单点 + 签名聚合降为 O(n)
• 优化对扩展性的意义

PBFT 在每阶段需要所有节点互相广播以收集投票，消息总数为 O(n²)，在节点数增大时开销急剧上升，限制了可扩展性。HotStuff 通过"每轮仅 leader 与所有节点通信 + 用 BLS 签名聚合把投票合并为一个证书"的方式，把每轮通信降为 O(n)。同时用链式确认（3-chain）替代 PBFT 的多阶段全互联，进一步简化。这种优化使共识可扩展到更多验证者，是 HotStuff 的核心工程贡献。

通信复杂度是共识可扩展性的关键。HotStuff 用"star 拓扑 + 聚合签名"把 O(n²) 降为 O(n)，牺牲了部分复杂度换取大规模扩展能力，是区块链共识工程的重要权衡。

• PBFT 视图切换依赖收集稳定检查点
• HotStuff 用链式 QC 简化视图切换
• 线性通信 vs 全互联

PBFT 的视图切换需要新的 primary 收集足够的稳定检查点并广播 view-change，其它副本验证后广播 new-view，视图切换交互复杂（全网通信、需收集 2f+1 个 view-change 消息），且需要额外的 checkpoint 机制来保证一致性。HotStuff 采用线性链式共识：每个视图只由一个 leader 提出，通过把 QC（quorum certificate）串成链（每个区块引用前一个 QC）实现，视图切换只需把"新的 QC"作为新 leader 的输入，无需额外收集稳定检查点，通信模式为线性（leader 依次向各副本发送，副本依次响应），复杂度从 O(n^2) 降到 O(n)。差异核心：PBFT 视图切换依赖多方收集稳定检查点（全互联、多轮广播），HotStuff 用链式 QC 与线性通信简化视图切换，在共识安全性上两者都容忍 f 个拜占庭节点，但 HotStuff 的链式结构使每个视图只需线性通信、更易工程化。

HotStuff 用"链式 QC"把视图切换简化为"沿用上一个 QC 继续出块"，省去 PBFT 视图切换时收集稳定检查点的多轮交互，配合线性通信（每视图 O(n)）显著降低复杂度，这是其成为主流 BFT 共识（如 LibraBFT）的原因。

• FLP 不可能性：异步模型中无法保证共识终止
• 部分同步模型引入 GST 后保证终止
• BFT 协议在 GST 后达成共识

FLP 不可能性定理指出：在完全异步模型中，存在一个消息丢失（或无限延迟）的故障进程，使任何共识算法都无法保证终止。为绕开这一不可能性，部分同步（partial synchrony）模型假设：存在一个未知的全局稳定时间（GST），在 GST 之后，网络消息的延迟有界（即网络恢复同步）。只要系统在 GST 前可能不确定，但 GST 后网络变得可预测，协议就能在 GST 后保证终止。BFT 协议（如 PBFT、HotStuff）都假设 GST：它们在网络行为异常时保持安全（不提交错误值），并在 GST 后借助有界延迟完成共识（终止）。因此部分同步模型在"安全始终成立、活性在 GST 后成立"的意义上绕开了 FLP。

部分同步模型是"安全与活性"的平衡：安全在任何时刻成立，活性只需在 GST 后成立。GST 使协议能在"网络可能无限慢"的现实与"必须终止"的目标之间找到可行解，是 BFT 共识的普遍假设。

• checkpoint 定期记录状态摘要
• 用 digest 比较、2f+1 确认形成 stable checkpoint
• 防止恶意节点伪造检查点

PBFT 中，节点定期向其他节点广播 checkpoint（包含当前状态摘要 digest），收到 2f+1 个一致 checkpoint 的节点形成 stable checkpoint，从而可以安全清理该 checkpoint 之前的日志。digest 比较用于验证：各节点用相同 digest 确认状态一致，只有 2f+1 个节点确认相同 digest 才信任该 checkpoint。由于协议假设至少 2f+1 个节点诚实，因此这些节点不会伪造一致的 digest，从而防止恶意节点伪造检查点（恶意节点无法凑齐 2f+1 个一致伪造）。stable checkpoint 还用于 view change 时同步状态，保证新视图从已确认状态继续。

checkpoint 机制解决"日志无限增长"与"状态同步"两个问题。digest 一致性 + 2f+1 多数确认是防伪造的关键：恶意节点无法伪造一个被多数诚实节点认同的检查点。这一机制也体现了 PBFT 中"多数诚实"假设的应用。

• Pre-prepare：primary 提议
• Prepare：节点确认收到提议并一致
• Commit：节点确认已准备并提交

PBFT 的三阶段：Pre-prepare 阶段，primary 向其他节点广播带序号的提议；Prepare 阶段，各节点收到后向所有节点广播 Prepare 消息，当收到 2f+1 个一致的 Prepare 后进入准备状态；Commit 阶段，各节点广播 Commit 消息，当收到 2f+1 个一致 Commit 后提交该操作。三阶段通过 2f+1 多数确认，保证在任意视图下节点对操作的顺序达成一致，且恶意节点无法单独制造分歧。三阶段共同提供共识的确定性顺序与容错。

三阶段是 PBFT 安全性的核心：Pre-prepare 建立提议，Prepare 保证"诚实节点对提议一致"，Commit 保证"即使视图切换，已提交操作不被回退"。每一阶段都以 2f+1 多数为前提，源于 3f+1 容错的节点数。

• 区块链无信任中心的场景需要 BFT
• 拜占庭节点假设（恶意挖矿/验证者）
• 由 3f+1 与 2/3 诚实前提

区块链在无信任中心、节点可能被攻击或作恶的环境中，需要用 BFT 共识保证安全与确定性。拜占庭节点假设指任意节点可能被攻击、发送错误消息或恶意行为，因此协议必须假设不超过 f 个节点作恶（3f+1 保证 2/3 诚实）。BFT 共识（如 Tendermint、HotStuff）通过多轮投票与 2/3 多数确认，保证在恶意节点存在时仍能对区块达成一致并确定性终结。这一假设是区块链抵抗双花、分叉等攻击的基础。

区块链的信任模型要求"无需信任任何单一节点"，因此必须用 BFT 而非 CFT。拜占庭假设使协议能抵抗恶意攻击，是区块链安全性的基石，代价是更高的节点冗余与通信成本。

• 3f+1 是 BFT 的最小节点数
• 安全性论证：2/3 诚实
• 与 CFT 2f+1 的对比

BFT 需要 3f+1 个节点才能容忍 f 个拜占庭故障，其必要性源于：节点可能"撒谎"，因此不能像 CFT 那样只假设多数诚实。在 3f+1 节点中，最多有 f 个作恶、其余 2f+1 个诚实。安全性要求"任何 2f+1 多数子集相交"，且保证诚实节点占 2/3。若节点数少于 3f+1（如 2f+1），则可能 f 个恶意节点与 f 个诚实节点组成的集合无法区分，导致无法保证一致。因此 3f+1 是权衡"冗余、通信成本与安全性"的最小节点数，保证 2/3 诚实前提。

3f+1 的由来是"2f+1 个多数子集必须相交且诚实节点占优"。当只有 2f+1 节点时，恶意节点可能伪装成多数，无法保证安全。3f+1 使诚实节点始终占 2/3，是 BFT 安全性的必要条件。