[1] Paxos made live: an engineering perspective, Tushar Chandra, Robert Griesemer and Joshua Redstone, ACM Symposium on Principles of Distributed Computing, 2007

Paxos 并不适合于拜占庭容错系统，譬喻下图中，N2 处事器伪造数据，就会让 Paxos 系统无法告竣共鸣。

liveness：可以接管而且执行非拜占庭客户端的请求，不会被任何因素影响而导致非拜占庭客户端的请求不能执行。

PBFT 在许多场景都有应用，譬喻 Liskov 曾经把它用于一种 NFS 的实现，最近一个热门的应用是在 IBM 主导的区块链超等账本项目中，除了 PBFT 之外，超等账本项目还引入了基于 PBFT 的自用共鸣协议 Sieve[5]，它的目标是但愿在 PBFT 基本之上可以或许对节点的输出也做好共鸣，这是因为超等账本项目标一个重要成果是提供区块链之上的智能合约——就是在区块链上执行的一段代码，因此它会带来区块链账本上最终状态的不确定，为此 Sieve 会在 PBFT 实现的基本之上引入代码执行功效签名举办验证。

拜占庭系统每执行一个请求，处事器需要记录日志。假如日志得不到实时的清理，就会导致系统资源被大量的日志所占用，影响系统机能及可用性。另一方面，由于拜占庭处事器的存在，一致性协议并不能担保每一台处事器都执行了沟通的请求，所以 , 差异处事器状态大概纷歧致。周期性的查抄点协议可以按期地处理惩罚日志，实时更正处事器状态。

假如输入的信息正确，那么所有非拜占庭处事器必需接管这个信息，并计较相应的功效。

把拜占庭容错系统的场景放松，不答允系统中呈现叛徒（也就是说没有黑客进攻，不会呈现伪造动静等环境），这样对付数据中心漫衍式系统构建是普遍环境。Paxos 是第一个合用于这种系统的共鸣算法，但不合用于拜占庭容错系统（Byzanetine Paxos 除外）。Paxos 运行在称为副本的一组历程荟萃，这些历程需要在纵然产生错误的环境下也能在某一个值上告竣一致，假如半数以上的副本在足够长的时间内没有产生 crash，那么所有运行中的副本将可以在某个提出的 value 上告竣一致：在状态机复制中，这意味着需要在“(多副本) 日志中的下一笔记录是哪条”上告竣一致。

借用吴镝的图说明下 Paxos 进程：Paxos 分为 Prepare 和 Accept 两个阶段。协议中有两个主要的脚色，Proposer 和 Acceptor。value 被大大都接管之前，每个 Acceptor 可以 accept 多个差异的值。可是，一旦一个 value 被 majority accept(即 value 告竣一致)，那么这个 value 就不会变了。因为 Prepare 阶段会将该 value 给找出来，随后 Accept 阶段会利用这个 value，后续的所有的提案城市选择这个 value。 需要留意的是，每个阶段都是收到 majority 的响应后即开始处理惩罚。而且由于呆板会宕机，Acceptor 需要对 acceptedProposalID，acceptedValue 和 minProposal 举办耐久化。 从流程中可以看出 Prepare 有两个浸染 :

假如系统中有 3f+1 个节点，那么 PBFT 可以容忍拜占庭处事器不高出 f 个。简朴表明一下原因：假设有三个将军 , 只有一个叛徒。假如 A 是叛徒，那么 A 大概会给 B 发出打击，然后给 C 发出后退的呼吁。当 B 和 C 互沟通步信息的时候他们会发明两个纷歧致的信息。可是 B 和 C 谁也无法判定谁是叛徒，好比从 B 的角度来看，他无法判定 A 是叛徒可能 C 是叛徒。所以三个将军里有一个叛徒是无法办理的。为了确保正确，PBFT 两两交互确定交集后才气确定一个非叛徒：因此由-(N-f)＋(N-f)-N>=f+1 推导出 N>=3f+1。

同盟链：半关闭生态的生意业务网络，存在差池等信任的节点；

在实际网络中，拜占庭系统需要指数级的算法才气办理，跟着大局限漫衍式系统尤其是云计较的鼓起，通过放松 liveness 来提高机能的简化拜占庭协议也不绝涌现并在详细系统中获得运用，譬喻 PBFT ，Paxos，Raft 等等。从今朝研究近况来看，拜占庭系统的设计主要分为状态机拜占庭协议和 Quorum 拜占庭协议。两种协议在成果上的主要区别在于：前者需要给所有的请求布置序号，所有请求必需按顺序执行，主要用于对付系统状态敏感的漫衍式计较系统中；后者不需要为请求布置序号，多个请求可以同时执行，主要被应用于漫衍式存储系统中。拜占庭容错技能的研究偏向主要是低落系统开销 , 缩小与今朝实际应用中的系统之间的差距。

PBFT 采纳的设计思路是将所有的事情都放在处事器端举办，譬喻告竣一致性，监测拜占庭主节点等。因此，它的一致性协议设谋略巨大，个中有两个阶段需要处事器之间的两两交互，数据处理惩罚量大，计较巨大。

其次的不同在于副本之间的通信机制。Zab 回收动静模子，每次更新都需要至少三个动静：提议，确认，和提交，如上图所示，而 Raft 则依赖 RPC。

状态机拜占庭系统的特点是整个系统配合维护一个状态，所有处事器采纳一致的动作，包括三种协议：一致性协议 agreement，查抄点协议 checkpoint，视图改换协议 view change。

一旦主节点自身产生错误，就大概导致从节点吸收到具有沟通序号的差异请求，可能同一个请求被分派多个序号等问题，这将直接导致请求不能被正确执行。视图改换协议的浸染就是在主节点不能继承推行职责时，将其用一个从节点替换掉，而且担保已经被非拜占庭处事器执行的请求不会被改动。

一致性协议的方针是使来自客户端的请求在每个处事器上都凭据一个确定的顺序执行。一般有一个节点作为主节点，认真将客户端的请求排序，其余是从节点，凭据主节点提供的顺序执行请求。所有的处事器在沟通的设置信息下事情，这个设置信息称为 view，每改换一次主节点，view 随之产生变革。一致性协议包括至少三个阶段，发送请求 request，序号分派 pre-prepare，和返回功效 reply。按照协议设计差异，还大概会包括交互 prepare，序号确认 commit 等阶段。

在所有 Paxos 类协议中，每个值 (就是提案) 实质上就是一条日志记录，记录由两部门标志，在 Paxos 中叫做 slot 和 ballot，在 Zab 中叫 epoch 和 counter，在 Raft 中叫 term 和 index。当 Leader 针对当前日志广播提案时，跟从者依据法定大都 (Quorum) 选举，而且在 Leader 提交后在当地应用该提案。所有的 Paxos 类协议都是保障全局顺序的。

郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。