分布式系统是在研究区块链过程中必不可少的部分，在我们进行区块链编程前，一定要打好基础。

接下来的几篇文章，将研究常见的共识算法，非拜占庭容错共识算法Paxos和Raft，以及拜占庭容错算法PBFT、PoW、PoS以及DPoS。

Paxos是一个在不可靠网络环境下解决共识问题的算法。共识是一群参与者对一个结果达成意见一致的过程。

故障模型

分布式系统中几种常见的故障模型，也是上述这些共识算法存在的本质原因。从最特定最简单的到最广泛最复杂的顺序排序：

• Crash-stop Failures：一旦发生故障，节点就停止提供服务，并且不会恢复。这种故障模型中的节点都按照正确的逻辑运行，可能宕机，可能网络中断，可能网络延迟，但结果总是正确的。
• Omission Failure：相对于Crash-stop Failures，这种故障模型允许节点在故障发生后恢复，但消息不会恢复，比如网络故障造成某条消息在传输过程中丢失（不是延迟）。
• Crash-recovery Failures：相对于Omission Failures，这种故障模型节点在恢复时可能需要一些持久化的数据恢复状态（Omission）。节点crash之前能把状态完整的保存在持久存储上，重启之后再次按照以前的状态继续执行和通信，比如Basic Paxos中要求节点必须把ballot number记录到持久存储中，一旦crash，修复之后必须继续记住之前的ballot number。（节点总是按照程序逻辑执行，结果总是正确的，但不保证消息返回的时间）
• Byzantine Failures：这种故障模型需要处理拜占庭问题，因此也是最难处理的，相对于以上两种故障模型，不仅仅节点宕机或网络故障会发生，节点还可能返回随机或恶意的结果，传输过程中数据被篡改，甚至有可能影响其他节点的正常运行。（节点不按程序逻辑执行，对它的调用返回随意或混乱的结果）

Paxos是基于Crash-recovery Failures，适合安全的网络环境，被在内网服务的存储或协调服务大量使用。
PBFT和区块链的其他共识算法是基于Byzantine Failures，面向更复杂的环境。

Paxos

Paxos的网络环境可能会出现故障，但绝不会出错，因此可以信任所有节点的交互结果。为了便于描述问题，做出以下假设：

• 假设
  • 机器节点
    • 机器处理速度是任意的，即完成时间不确定。
    • 机器可能会发生故障
    • 具有稳定存储的机器可能在故障恢复后重新加入协议（遵循 Crash-recovery Failures 模型）
  • 网路
    • 任意机器之间可以通信。
    • 消息是异步发送，传输时间不确定。
    • 消息可能丢失、乱序或重复。
    • 消息在传递过程中不会被篡改（也就是说，拜占庭问题不会发生。）
  • 节点数目
    一般而言，共识算法可以使用2F+1个节点，只要同时出现故障的节点数目不超过F，共识算法就能保证整个协议正常工作。

Paxos协议通过角色来描述节点的行为，分别是 client、acceptor、proposer、learner以及leader。在典型的实现中，单个节点同时扮演一个或多个角色。这不影响协议的正确性 —— 通常通过合并角色来减少网络延迟。

• 角色

  • Client
    Client发送一个请求到分布式系统，并等待应答。例如，分布式文件系统中在一个文件上的写请求。
  • Acceptor(Voter)
    Acceptor充当协议的容错「内存」。Acceptor被集合到一个叫Quorum的组。
    1.任何发送给一个Acceptor的消息都必须发送给Acceptors的一个Quorum。
    2.从一个Acceptor接收的任意消息可能会被忽略，除非副本接收自Quorum的每个Acceptor。
  • Proposer
    Proposer接收Client的请求，然后试图说服Acceptor同意Client的请求，并在冲突发生时担任推动协议的协调者。
  • Learner
    Learner扮演协议的复制因子。一旦Client请求被Acceptors接收，Learner可能会执行操作。（也就是说，执行请求并返回应答给客户端）。为了提高处理的可用性，可以添加额外的Learner。
  • Leader
    Paxos需要一个突出的Propose（称作Leader）来处理请求。许多Proposer都认为自己是Leader，但是协议最终选择一个Leader。如果有两个Leader，那么他们可能会在提交请求时不断地遇到冲突。

• 阶段
  Paxos协议的处理流程分为两个阶段：

  • 阶段 1a：Prepare
    Proposer选取Proposal number N并像所有Acceptor发送prepare消息。
  • 阶段 1b：Promise
    Acceptor收到Prepare消息后，如果N不小于其Promise过的任何其他Prepare消息，则答复Promise，保证不再响应小于N的提议。
  • 阶段 2a：Accept Request
    Proposer接收到超过半数的Promise消息，设置提议内容并向所有Acceptor发送Accept消息。

  • 阶段 2b：Accepted
    Acceptor同意（Accepted）当前的Accept消息，并通知每个Learner。

    
    

在第一阶段，当Acceptor接收Proposer的提议，并不代表其同意（Accepted）提议，而是不再接受比其提议编号小的提议