嘿，刚好啃过OSDI'99那篇PBFT的原始论文，来帮你把这两个疑问掰明白：

答案很明确：这个摘要是副本节点自己独立生成的，不过它得和Pre-prepare消息里主节点附带的请求摘要做一致性校验。

具体来说，主节点发送的Pre-prepare消息里包含了视图号v、序列号n、客户端请求m的摘要d，还有主节点自己的数字签名。副本收到这条消息后，会先做几件事：

• 验证主节点的签名合法性
• 自己重新计算客户端请求m的哈希摘要，和Pre-prepare里的d比对，确保主节点没篡改请求内容
• 确认这个序列号n在当前视图下没有被用过，也不在水线（watermark）之外

只有这些校验都通过了，副本才会生成带自己签名的Prepare消息，消息里的核心内容就是<v, n, d>——这里的d就是副本自己计算并验证过的请求摘要，不是直接用主节点给的那个（当然两者必须完全一致）。这么设计的目的是防止恶意主节点伪造请求，用多副本独立计算摘要的方式来保证请求的真实性。

PBFT专门设计了追赶同步（Catch-up）机制来处理这种情况，步骤大概是这样的：

1. 视图同步：节点上线后，首先会向其他在线节点发送视图查询请求，获取当前系统的活跃视图号v，确保自己和集群处于同一视图下。如果当前视图已经切换过，它还得同步视图切换的相关信息（比如新主节点的选举结果）。
2. 状态同步：节点会检查自己本地的日志和检查点（checkpoint），找到自己最后一个稳定的检查点（也就是已经被2f+1个节点确认的状态快照），然后向其他节点请求这个检查点之后的所有共识消息（Pre-prepare、Prepare、Commit），以及对应的请求内容。
3. 日志回放与状态更新：拿到缺失的日志后，节点会重新执行这些请求，把自己的状态更新到集群当前的最新状态。同时它会验证这些日志的合法性（比如每个请求都有足够的Prepare和Commit签名），确保没有被篡改。
4. 重新加入共识：当节点的状态和集群其他节点一致后，它就可以正常接收新的客户端请求，参与Pre-prepare、Prepare、Commit的共识流程了。

另外，如果离线时间太长，节点可能需要直接请求其他节点的最新检查点快照，跳过中间的日志回放，这样能更快地追上集群状态——这也是PBFT里检查点机制的核心作用之一：减少需要同步的日志量，提升恢复效率。

内容的提问来源于stack exchange，提问作者ezio