区块链中的 PBFT 不需要第二次投票

区块链中的 PBFT 不需要第二次投票

💡 原文中文,约4000字,阅读约需10分钟。
📝

内容提要

本文讨论了PBFT中的第二次投票是否必要,通过逆向推导和正向理解得出结论认为一次投票就可以达到多数节点一致的结果。然而,PBFT及其变体仍然保留了两次投票的流程,作者对此感到困惑,并认为可能是自己对PBFT了解不够深入。

🔎

延伸解读

第二次投票:必要还是冗余?

文章通过逆向推导指出,第二次投票仅在恶意节点导致两次投票结果不一致时发挥作用。若所有诚实节点参与,一次投票即可达成一致。但作者也承认,第二次投票能提前发现故障,减少执行后回滚的成本,类似于TCP三次握手,虽非绝对必要,但增加了安全性。

视图切换下的状态一致性风险

在单次投票流程中,若节点在视图切换前未执行请求,切换后可能直接执行新请求,导致状态不一致。例如,节点A未执行P却执行了P',造成余额差异。两次投票通过commit阶段让节点在故障后能根据commit结果重新执行,但作者指出这并未完全避免问题,只是降低了风险。

有状态系统为何更灵活

区块链作为有状态系统,通过区块哈希和父哈希强制排序,节点能明确请求位置,及时同步缺失区块。因此,在区块链场景下,若仅追求多数节点最终一致,第二次投票并非必需。而无状态系统因缺乏执行记录,难以判断请求顺序,故需更谨慎的确认机制。

未解的困惑与设计权衡

作者最终仍困惑于为何PBFT及其变体(如Tendermint、HotStuff)都保留两次投票。他推测可能自己未触及真正需要第二次投票的场景,或现有资料未清晰阐述。这反映了分布式共识算法中安全性与效率的权衡,以及理论必要性与工程实践之间的差距。

❓

Q&A

PBFT中的第二次投票有什么作用?

第二次投票主要用于处理恶意节点的情况,如果结果一致则不需要进行第二次投票。

在什么情况下PBFT可以只进行一次投票?

当所有节点都是诚实节点时,系统可以通过一次投票达成一致。

为什么第二次投票并不是绝对必要的?

虽然第二次投票有助于增强系统的安全性,但并不能证明其绝对必要性,单次投票也能实现一致性。

PBFT的两次投票流程如何减少状态不一致的风险?

两次投票流程可以在节点故障发生时提供额外的确认,减少状态不一致的风险。

无状态系统与有状态系统在PBFT中的区别是什么?

无状态系统在处理请求时面临更大挑战,而有状态系统(如区块链)能够更好地管理执行记录。

作者对PBFT的理解存在哪些不足?

作者认为自己对PBFT的理解不够深入,尚未发现第二次投票真正必要的场景。

🏷️

标签

➡️

继续阅读