【问题标题】:PBFT view-change: What happens to committed operations after the valid snapshot?PBFT 视图更改:在有效快照之后提交的操作会发生什么?
【发布时间】:2017-07-11 05:14:40
【问题描述】:

PBFT 表示,如果备份 i 的计时器在视图 v 中到期,则它通过多播 <view-change, v+1, n, C, P, i> 开始 v+1 的视图更改,其中 n 是最后一个稳定检查点 s 的序列号,P 是包含 a 的集合为在 i 准备的每个请求 m 设置 Pm,其序列号高于 n。

现在,检查点是定期进行的,因此可以在 i 处准备好序列号大于 n 的消息,这些消息已经提交。我们不希望这些被包含在 Pm 中,因为它们已经被提交了。 那么,PBFT 是如何处理的呢?

【问题讨论】:

  • 更新:答案在论文的安全部分提到。假设 k 有一条消息 m,它在本地以序列号 n 提交。该算法对具有相同序列号 n 和新视图号的 m 重做原子多播协议的三个阶段,除非新视图消息包含具有稳定检查点且序列号大于 n 的视图更改消息.

标签: algorithm distributed-computing blockchain distributed-system


【解决方案1】:

我认为这些消息会再次执行。当 view-change 发生时,所有节点都将位于同一个检查点。

当视图v + 1 的“新”主接收到2⨍ 有效的视图更改消息时,多播新视图消息时间>。在发送的消息中表示:

  • V:一组已接收且有效的视图更改消息。
  • P:一组预先准备好的未处理消息。这些消息计算如下:
    • 从最后一个稳定检查点,您可以得到最后一个执行请求的序列号。该值将对应于min-s。
    • 获取您收到的所有准备好的消息中最大的序列号。该值将对应于max-s。
    • 因此,它会根据需要生成尽可能多的预先准备好的消息。

每个节点都会保存不在检查点内的消息的日志,因此不需要再次处理。

【讨论】:

  • 如果提交的消息不在检查点中,那么如果在视图更改期间再次执行它们,它不会改变节点的状态吗?为什么我们要再次为它们生成预先准备好的消息并检查日志以查看它们是否已被执行并且不是检查点的一部分?
  • 节点的状态设置为在检查点建立的状态,因此执行不会以不同的方式改变节点的状态。另一方面,我们不检查日志以查看消息是否已执行,但为了不必再次执行它们,我们重新加载上一次执行的结果。
猜你喜欢
  • 2021-07-06
  • 2019-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2014-05-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多