我知道此网站上存在一些问相同问题的问题。但是答案永远不清楚:
在PBFT中,为什么在准备了2/3秒后副本不能执行请求?为什么需要提交阶段?如果2/3 +1副本已同意准备,那么我认为他们可以执行请求而无需再次广播吗?
答案 0 :(得分:0)
假设没有提交阶段:
假定副本A已准备好( n,m ),然后立即执行 m ,而其他副本尚未准备并执行。但是,此时,会发生视图更改,并且新的主节点无法与A通信。因此,新的主节点将接受尚未准备并执行 m 的其他节点的2f + 1。 ,说明它们的最大序列号为n-1。
因此,在新视图中,主服务器可能为后续请求m'生成(n,m'),这与A的状态不同。
答案 1 :(得分:0)
PBFT确实需要提交阶段,以确保即使在视图更改期间也要为消息m分配序列号n。这是因为,如果在接收到2f + 1 COMMITS之后在某个副本中提交了序列号为n的消息m,则该消息(n,m)将包含在NEW-VIEW消息中,从而由新的主节点重新广播到所有其他节点。 >
这个问题使我困惑了很长时间,今天我明白了。我将尝试清楚地解释它,但我建议您对本文非常熟悉,至少您应该知道“准备”“ commit_local”是什么意思。
PBFT具有三种算法:
请求处理算法
查看更改
垃圾收集算法
从高层次来看,提交阶段可确保此不变性:
如果对于某些副本i,commit_local(n,m,v)为true,那么对于任何非故障副本i',commit_local(n,m',v + 1)为false。
证明:
在某个副本上到达Commit_local(n,m,v),我的意思是2f + 1副本(Q1)声明已准备好。这意味着Q1投票中有一些无故障的副本用于New-View消息中的View-Change。因此,在新视图消息中至少有一个准备好的消息(n,m)。该消息将与New-View消息一起广播到所有其他副本。
对于我收到“新视图”的任何副本,它可能具有两种状态:
1)它已经提交(n,m)
2)它尚未提交(n,m)。它可能正在等待COMMITS,PREPARE或什至PRE-PREPARE,无论如何。
在第二种情况下,它将针对v + 1从pre-prepare(n,m)阶段进行重新处理。因此,(n,m)在视图更改期间保持不变。总之,提交阶段将确保如果(n,m)在某个副本上已提交,则(n,m)将包含在NEW-VIEW中,因此它将在视图更改阶段发送到所有其他副本。 / p>
如果我们忽略提交阶段怎么办?安全性被破坏了,因为m可以在某些副本中以n提交,而另一个m'在某些其他副本中以n提交。
假设在视图v中准备好(m,n)之后,一个无故障的副本提交了请求。这意味着2f + 1个副本(Q1)声明它们已经为视图v中的(m,n)做好了准备/ p>
同时,由于网络已部分同步,因此可能尚未准备任何其他副本。超时后,将发生视图更改。
现在,由于未准备任何副本,因此某些仲裁可能不会发送序列号> = n的任何视图更改,因此在新的主max-s
现在,在视图更改期间,(n,m)在其他副本中提交,而(n,m')在其他副本中提交。
结论:提交阶段确保如果(n,m)在某个副本上已提交,则(n,m)将包含在NEW-VIEW中,因此它将在视图更改阶段发送到所有其他副本。 / p>