区块链系统中拜占庭容错PBFT工作的实现原理解析

在本文中，我们将了解区块链系统中实际拜占庭容错（PBFT）的工作，该算法背后的数学，其意义，编写其伪代码，然后使用node.js实现它。

容错与容错系统

想象一下你的车的发动机出了什么问题，但是它仍然在工作，但是车速大大降低了，我们称之为容错，它具有容错特性。

任何系统在未知或已知故障的影响下继续运行，导致系统容量降低，可称为容错系统，并具有容错特性。

与其他系统不同，容错系统在发生故障时不会崩溃，相反，即使出现故障，系统也会以较低的吞吐量或较高的延迟运行。

拜占庭容错

拜占庭故障特别存在于分布式系统中。这些故障是系统节点之间错误信息的结果。系统中存在的故障或错误信息的原因对于分布式系统的成员来说大多是未知的。因此，在这种情况下，一个节点可能行为异常，并向网络中的不同节点发送不同的响应，因此很难将该节点归类为恶意或故障。因此，为了对故障节点做出决策，系统的诚实节点达成共识，可以得出不受恶意/故障节点影响的结论的系统可以被视为拜占庭容错系统。

具有拜占庭容错能力的系统解决了拜占庭将军问题中出现的问题。

拜占庭容错系统没有识别出故障/恶意并找出问题所在，而是在没有系统成员出现故障的情况下继续运行。（因此吞吐量和效率会降低）

实战拜占庭容错

Castro和Liskov开发了一种新方法，可以在分布式系统中达成共识，通过复制节点/状态机来容忍故障/恶意节点。但是PBFT只能容忍这样的节点，直到故障节点的数量少于所有节点的三分之一。网络中的节点通过在彼此之间传递关于决策的消息来达成关于决策的共识。诚实的节点越多，系统就越安全。由于更多数量的诚实节点将就错误/恶意节点就不正确的决定达成一致而就正确决策达成一致，因此大多数人会拒绝虚假信息。

为了保证系统安全，pbft需要系统中3f + 1个节点，其中f是系统可以容忍的最大故障节点数。因此，对于要做出任何决定的节点组，需要来自2f + 1个节点的批准。

区块链中的PBFT

区块链中的实用拜占庭容错算法从分布式系统中使用的版本继承了许多概念。在这种情况下，达成共识以确定块的有效性。

系统中的节点彼此共享消息以向链提交块。在这种情况下，恶意节点可能广播被篡改的块，因此，被最大数量的节点视为有效的块被整个网络视为有效。

PBFT的意义

在比特币（工作证明）中，区块提议者是算力最快的矿工，而在利益证明中，区块提议者是最富有的矿工。在PBFT中，区块创建者可能不是任何特殊的矿工，但是提交给链的建议区块将是一致同意的区块。从而提供与PoW和PoS相同的目的，即向链添加新区块。

状态与消息

本节描述了每个节点在不同会话中的各种状态以及节点在任何一轮块建议期间相互传递的不同消息：

· NEW ROUND：提议者发送新的区块提案。验证者等待PRE-PREPARE消息。

· PRE-PREPARED：验证者已收到PRE-PREPARE消息并广播PREPARE消息。然后它等待PREFARE或COMMIT消息的2F + 1。

· PREPARED：验证者已收到2F + 1个PREPARE消息并广播COMMIT消息。然后它等待2F + 1 COMMIT消息。

· COMMITTED：验证者已收到2F + 1个COMMIT消息，并能够将建议的区块插入区块链。

· FINAL COMMITTED：成功地将新块插入到区块链中，并且验证者已准备好进行下一轮。

· ROUND CHANGE：验证者在同一个建议的轮数上等待2F + 1个ROUND CHANGE消息。

算法

NEW ROUND

· 提议者以循环方式选举产生。

· 提议者从事务池收集事务。

· Proposer创建一个区块提议并将其广播到网络。提议者的状态现在变为PRE-PERPARED状态。

· 验证者接收PRE-PREPARE消息并进入PRE-PREPARED状态。

· 验证这现在验证提议，然后向其他验证者广播PREPARE消息。

PRE-PREPARED

· 验证者等待2F + 1个有效的PREPARE消息，然后进入PREPARED状态。

· 验证者现在在进入PREPAPRED状态时广播COMMIT消息。

PREPARED

· 验证者等待2F + 1提交消息，然后进入COMMITTED状态。

COMMITTED

· 验证者将接收到的2F+1提交消息附加到块中，并将块添加到区块链中。

· 当区块插入到链中时，验证者现在转移为FINAL COMMITED状态。

FINAL COMMITTED

· 新一轮的提案选举将启动。

伪代码

本节介绍上述算法的伪代码：

// NEW_ROUND：

State = NEW_ROUND

proposer = get_proposers_address（ blockchain ）

if （ current_validator == proposer ）

block = create_block（ transaction_pool ）

broadcast_block（ block ）

State = PRE_PREPARED

// PRE_PREPARED：

ON message.type == PRE_PREPARE

verify_block（ message.block ）

verify_validator（ message.block ）

broadcast_prepare（ message.block ）

State = PREPARED

// PREPARED：

ON message.type == PREPARE

verify_prepare（ message.prepare ）

verify_validator（ message.prepare ）

prepare_pool.add（ message.prepare ）

if （ prepare_pool.length 》 2F+1 ）

broadcast_commit（ message.prepare ）

State = COMMITTED

// COMMITTED：

ON message.type == COMMIT

verify_commit（ message.commit ）

verify_validator（ message.commit ）

commit_pool.add（ message.commit ）

if （ commit_pool.length 》 2F+1 ）

commit_list = commit_pool.get_commits（）

block.append（ commit_list ）

blockchain.append（ block ）

State = FINAL_COMMITTED

// FINAL_COMMITTED：

new_round（）

本节将以图解方式说明算法，以便更好地理解：

在新一轮开始之前，在节点之间广播事务，以便所有节点在其池中具有相同的事务。 在池中有足够数量的事务之后，这些节点开始新一轮。

提议者以循环方式选择。 节点8成为提议者，其余节点就此达成一致。 提议者发送PRE-PREPARE消息，每个节点进入PRE-PREPARED状态。

提议者广播PRE-PREPARE消息，其中包含建议的区块。 其余节点将此消息广播到其他节点。

如果每个节点就建议的区块达成一致，则发送PREPARE消息。 在2F + 1这样的消息之后，节点将状态改变为PREPARED。

准备好的节点互相发送COMMIT消息，在2F + 1提交后，节点移动到COMMIT状态并将区块添加到链中。 添加区块后，它们将移至FINAL COMMITTED状态。

在FINAL COMMITTED之后，节点计算一个新的提议者。