拜占庭共识算法《拜占庭共识算法实验》
共识算法4 (BFT)
拜占庭将军问题（Byzantine Generals Problem），由Leslie Lamport、Robert Shostak和Marshall Pease，在其同名论文中提出（1982年）。拜占庭将军问题现在主要指分布式对等网络节点间的通信容错问题。在分布式网络中，不同的计节点通过交换信息达成共识。但有时候，系统中的成员节点可能出错而发送错误的信息，用于传递信息的通讯网络也可能导致信息损坏，也可能存在恶意节点或被黑客攻破的节点故意发送错误的信息，从而导致系统无法达成共识或者达成错误的共识。（参考： BFT Wikipedia ）
拜占庭将军问题提出后，有很多的算法被提出用于解决这个问题。这类算法统称拜占庭容错算法（BFT: Byzantine Fault Tolerance）。BFT从上世纪80年代开始被研究，目前已经是一个被研究得比较透彻的理论，具体实现都已经有现成的算法。
BFT算法中最典型的是PBFT（Practical BFT）。PBFT是由Miguel Castro和Barbara Liskov于1999年提出。PBFT算法解决了之前拜占庭容错算法效率不高的问题，将算法复杂度由指数级降低到多项式级，使得拜占庭容错算法在实际系统应用中变得可行。PBFT在保证安全性和可用性的前提下，提供了 (n-1)/3 的容错性。（细节请参考： PBFT ）
PBFT之后，很多进一步提升性能或鲁棒性的BFT算法先后被提出，例如Zyzzyva、ABsTRACTs、Aardvark、RBFT等等。近几年，由于区块链的热度，无数针对区块链应用场景优化过的BFT算法也不断涌现出来。虽然目前PBFT已经不能说是最好的，或最适合区块链的BFT算法。但是PBFT已经足够好了，而且在实际应用中已经非常成熟。
在BFT共识机制中，网络中节点的数量和身份必须是提前确定好的。BFT共识机制无法做到PoW共识机制中实现的任何人都可以随时加入挖矿。另外，BFT算法无法应用到大量的节点，业内普遍认为100个节点是BFT算法的上限。所以BFT算法无法直接用于公有链，BFT算法适合的场景是私有链和联盟链。业内大名鼎鼎的联盟链Hyperledger fabric v0.6采用的是PBFT，v1.0又推出PBFT的改进版本SBFT。这里再顺便提一句，在可信环境下共识算法一般使用传统的分布式一致算法PAXOS或者RAFT。
公有链使用BFT的一个例外是NEO，NEO使用了DBFT（delegated BFT）共识机制。DBFT共识机制下投票选出7个共识节点。这些代理节点是通过静态选出的，并完全由项目方部署。这也是NEO被外界质疑过于中心化的原因。（参考： 早期公有链明星项目-NEO ）
BFT算法和公有链合适的结合点在于基于BFT的PoS共识算法（BFT based PoS）。基于BFT的PoS共识算法要点有：一，网络节点通过锁定虚拟资产申请成为区块链系统的验证者（或矿工）。系统验证者的数量是动态变化的。二，系统从当前验证者中随机选择一个人作为区块提案人。三，系统验证者对区块提案进行投票表决，投票可能要进行多轮才能达成共识。每个人的投票比重与锁定的虚拟资产成比例。
基于BFT的PoS的典型例子是tendermint（Cosmos采用了tendermint作为共识核心）。
共识算法：Raft
上篇讲到了「拜占庭将军问题」：多个拜占庭将军要如何在可能有叛徒、信使可能被策反或者暗杀的情况下达成是否要进攻的一致性决定？还不了解的先看看上一篇 《拜占庭将军问题》 。这篇主要是介绍简化版拜占庭将军问题的解决方案：Raft 共识算法。
所以将拜占庭将军问题根据常见的工作上的问题进行简化： 假设将军中没有叛军，信使的信息可靠但有可能被暗杀的情况下，将军们如何达成一致性决定？
对于这个简化后的问题，有许多解决方案，第一个被证明的共识算法是 Paxos，由拜占庭将军问题的作者 Leslie Lamport 在1990年提出，最初以论文难懂而出名，后来这哥们在2001重新发了一篇简单版的论文 Paxos Made Simple ，然而还是挺难懂的。
因为 Paxos 难懂，难实现，所以斯坦福大学的教授在2014年发表了新的分布式协议 Raft。与 Paxos 相比，Raft 有着基本相同运行效率，但是更容易理解，也更容易被用在系统开发上。
我们还是用拜占庭将军的例子来帮助理解 Raft。
Raft 的解决方案大概可以理解成 先在所有将军中选出一个大将军，所有的决定由大将军来做。 选举环节 ：比如说现在一共有3个将军 A, B, C，每个将军都有一个 随机时间 的倒计时器，倒计时一结束，这个将军就会把自己当成大将军候选人，然后派信使去问其他几个将军，能不能选我为总将军？假设现在将军A倒计时结束了，他派信使传递选举投票的信息给将军B和C，如果将军B和C还没把自己当成候选人（倒计时还没有结束），并且没有把选举票投给其他，他们把票投给将军A，信使在回到将军A时，将军A知道自己收到了足够的票数，成为了大将军。在这之后，是否要进攻就由大将军决定，然后派信使去通知另外两个将军，如果在一段时间后还没有收到回复（可能信使被暗杀），那就再重派一个信使，直到收到回复。
故事先讲到这里，希望不做技术方面的朋友可以大概能理解 Raft 的原理，下面从比较技术的角度讲讲 Raft 的原理。
从拜占庭将军的故事映射到分布式系统上，每个将军相当于一个分布式网络节点，每个节点有 三种状态：Follower，Candidate，Leader ，状态之间是互相转换的，可以参考下图，具体的后面说。
每个节点上都有一个倒计时器 (Election Timeout)，时间随机在 150ms 到 300ms 之间。有几种情况会重设 Timeout：
在 Raft 运行过程中，最主要进行两个活动：
假设现在有如图5个节点，5个节点一开始的状态都是 Follower。
在一个节点倒计时结束 (Timeout) 后，这个节点的状态变成 Candidate 开始选举，它给其他几个节点发送选举请求 (RequestVote)
其他四个节点都返回成功，这个节点的状态由 Candidate 变成了 Leader，并在每个一小段时间后，就给所有的 Follower 发送一个 Heartbeat 以保持所有节点的状态，Follower 收到 Leader 的 Heartbeat 后重设 Timeout。
这是最简单的选主情况， 只要有超过一半的节点投支持票了，Candidate 才会被选举为 Leader ，5个节点的情况下，3个节点 (包括 Candidate 本身) 投了支持就行。
一开始已经有一个 Leader，所有节点正常运行。
Leader 出故障挂掉了，其他四个 Follower 将进行重新选主。
4个节点的选主过程和5个节点的类似，在选出一个新的 Leader 后，原来的 Leader 恢复了又重新加入了，这个时候怎么处理？在 Raft 里，第几轮选举是有记录的，重新加入的 Leader 是第一轮选举 (Term 1) 选出来的，而现在的 Leader 则是 Term 2，所有原来的 Leader 会自觉降级为 Follower
假设一开始有4个节点，都还是 Follower。
有两个 Follower 同时 Timeout，都变成了 Candidate 开始选举，分别给一个 Follower 发送了投票请求。
两个 Follower 分别返回了ok，这时两个 Candidate 都只有2票，要3票才能被选成 Leader。
两个 Candidate 会分别给另外一个还没有给自己投票的 Follower 发送投票请求。
但是因为 Follower 在这一轮选举中，都已经投完票了，所以都拒绝了他们的请求。所以在 Term 2 没有 Leader 被选出来。
这时，两个节点的状态是 Candidate，两个是 Follower，但是他们的倒计时器仍然在运行，最先 Timeout 的那个节点会进行发起新一轮 Term 3 的投票。
两个 Follower 在 Term 3 还没投过票，所以返回 OK，这时 Candidate 一共有三票，被选为了 Leader。
如果 Leader Heartbeat 的时间晚于另外一个 Candidate timeout 的时间，另外一个 Candidate 仍然会发送选举请求。
两个 Follower 已经投完票了，拒绝了这个 Candidate 的投票请求。
Leader 进行 Heartbeat， Candidate 收到后状态自动转为 Follower，完成选主。
以上是 Raft 最重要活动之一选主的介绍，以及在不同情况下如何进行选主。
Raft 在实际应用场景中的一致性更多的是体现在不同节点之间的数据一致性，客户端发送请求到任何一个节点都能收到一致的返回，当一个节点出故障后，其他节点仍然能以已有的数据正常进行。在选主之后的复制日志就是为了达到这个目的。
一开始，Leader 和 两个 Follower 都没有任何数据。
客户端发送请求给 Leader，储存数据 “sally”，Leader 先将数据写在本地日志，这时候数据还是 Uncommitted (还没最终确认，红色表示)
Leader 给两个 Follower 发送 AppendEntries 请求，数据在 Follower 上没有冲突，则将数据暂时写在本地日志，Follower 的数据也还是 Uncommitted。
Follower 将数据写到本地后，返回 OK。Leader 收到后成功返回， 只要收到的成功的返回数量超过半数 (包含Leader) ，Leader 将数据 “sally” 的状态改成 Committed。( 这个时候 Leader 就可以返回给客户端了)
Leader 再次给 Follower 发送 AppendEntries 请求，收到请求后，Follower 将本地日志里 Uncommitted 数据改成 Committed。这样就完成了一整个复制日志的过程，三个节点的数据是一致的，
在 Network Partition 的情况下，部分节点之间没办法互相通信，Raft 也能保证在这种情况下数据的一致性。
一开始有 5 个节点处于同一网络状态下。
Network Partition 将节点分成两边，一边有两个节点，一边三个节点。
两个节点这边已经有 Leader 了，来自客户端的数据 “bob” 通过 Leader 同步到 Follower。
因为只有两个节点，少于3个节点，所以 “bob” 的状态仍是 Uncommitted。所以在这里， 服务器会返回错误给客户端
另外一个 Partition 有三个节点，进行重新选主。客户端数据 “tom” 发到新的 Leader，通过和上节网络状态下相似的过程，同步到另外两个 Follower。
因为这个 Partition 有3个节点，超过半数，所以数据 “tom” 都 Commit 了。
网络状态恢复，5个节点再次处于同一个网络状态下。但是这里出现了数据冲突 “bob” 和 “tom”
三个节点的 Leader 广播 AppendEntries
两个节点 Partition 的 Leader 自动降级为 Follower，因为这个 Partition 的数据 “bob” 没有 Commit，返回给客户端的是错误，客户端知道请求没有成功，所以 Follower 在收到 AppendEntries 请求时，可以把 “bob“ 删除，然后同步 ”tom”，通过这么一个过程，就完成了在 Network Partition 情况下的复制日志，保证了数据的一致性。
Raft 是能够实现分布式系统强一致性的算法，每个系统节点有三种状态 Follower，Candidate，Leader。实现 Raft 算法两个最重要的事是：选主和复制日志
参考链接：
Raft 官网：
Raft 原理动画 (推荐看看)：
（本来不想一个个图片粘，但是在国内时候访问不了这个链接，干脆就复述了一遍整个过程。）
拜占庭容错和PBFT共识算法
实用的拜占庭容错算法
BFT 是区块链共识算法中，需要解决的一个核心问题。比特币的POW，eos的dpos，以及共识算法pos，这些公链算法，解决的是共识节点众多情况下的bft问题。
拜占庭将军问题。也称为拜占庭容错。
用来描述分布式系统一致性问题。
背景如下：
拜占庭帝国想要进攻一个强大的敌人，为此派出了10支军队去包围这个敌人。这个敌人虽不比拜占庭帝国，但也足以抵御5支常规拜占庭军队的同时袭击。这10支军队在分开的包围状态下同时攻击。他们任一支军队单独进攻都毫无胜算，除非有至少6支军队（一半以上）同时袭击才能攻下敌国。他们分散在敌国的四周，依靠通信兵骑马相互通信来协商进攻意向及进攻时间。困扰这些将军的问题是，他们不确定他们中是否有叛徒，叛徒可能擅自变更进攻意向或者进攻时间。在这种状态下，拜占庭将军们才能保证有多于6支军队在同一时间一起发起进攻，从而赢取战斗？
单从上面的说明可能无法理解这个问题的复杂性，我们来简单分析一下：
先看在没有叛徒情况下，假如一个将军A提一个进攻提议（如：明日下午1点进攻，你愿意加入吗？）由通信兵通信分别告诉其他的将军，如果幸运中的幸运，他收到了其他6位将军以上的同意，发起进攻。如果不幸，其他的将军也在此时发出不同的进攻提议（如：明日下午2点、3点进攻，你愿意加入吗？），由于时间上的差异，不同的将军收到（并认可）的进攻提议可能是不一样的，这是可能出现A提议有3个支持者，B提议有4个支持者，C提议有2个支持者等等。
再加一点复杂性，在有叛徒情况下，一个叛徒会向不同的将军发出不同的进攻提议（通知A明日下午1点进攻， 通知B明日下午2点进攻等等），一个叛徒也会可能同意多个进攻提议（即同意下午1点进攻又同意下午2点进攻）。
叛徒发送前后不一致的进攻提议，被称为“拜占庭错误”，而能够处理拜占庭错误的这种容错性称为「Byzantine fault tolerance」，简称为BFT。
使用密码学算法保证节点之间的消息传送是不可篡改的， 通过下面的算法我们可以保证A将军收到B将军发来的消息确实是B将军本人的真实请求 。
我们采用的是哈希函数（散列算法）SHA256 – 从数据（byte）值中创建独一无二的hash值，并压缩成摘要，将数据格式固定下来。通过这个摘要与个人私钥生成Digital Signature 和个人公钥Public-key certificate，接收方验证签名和摘要，如果是通过验证，即证明摘要内容没有经过篡改。
pbft容忍无效或者恶意节点数量 e 。为了保证整个系统可以正常运作，需要有2f+1个正常节点，系统的总结点数为 ：3f+1。即pbft算法容忍小于1/3的恶意或者无效节点。 原因见节点作恶的极端情况
pbft是一种状态机副本复制算法，所有副本在一个view轮换过程中操作，哪些是主节点（进攻的提议者的大将军们，轮流当）通过view中其他节点（其他将军）赋予的编号和节点数集合来确定，即：主节点p=v mod |R| 。 v：view编号，|R|节点个数，p：主节点编号。 关于状态机复制算法、view change的意义（主要是防止主节点作恶），主节点详见论文。
基于拜占庭将军问题，PBFT算法一致性的确保主要分为这三个阶段：预准备（pre-prepare）、准备(prepare)和确认(commit)。流程如下图所示：
[图片上传失败…(image-e3329d-1562488133052)]
首先解释一下上面各个符号表达的意思：
下面结合上图，详细说一下PBFT的步骤：
根据上述流程，在 N ≥ 3F + 1 的情况下一致性是可能解决， N为总计算机数，F为有问题的计算机总数 。
下面所有的校验流程略去对消息内容、签名和身份的验证，即已经保证了节点之间消息传播是不可篡改的
上述算法中，比较重要的一个点是view change，为了能恢复之前的请求，每一个副本节点收到消息之后或者发送消息的时候都会记录消息到本地的log记录中。当执行请求后，副本节点需要把之前该请求的记录消息清除掉。最简单的做法是在reply消息后，在执行一次当前状态的共识同步，但是为了节省资源，一般在多条请求K后执行一次状态同步。这个状态同步就是checkpoint消息。
为了节省内存，系统需要一种将日志中的 无异议消息记录 删除的机制。为了保证系统的安全性，副本节点在删除自己的消息日志前，需要确保至少 f+1 个正常副本节点执行了消息对应的请求，并且可以在视图变更时向其他副本节点证明。另外，如果一些副本节点错过部分消息，但是这些消息已经被所有正常副本节点删除了，这就需要通过 传输部分或者全部服务状态实现该副本节点的同步 。因此，副本节点同样需要证明状态的正确性。
在每一个操作执行后都生成这样的证明是非常消耗资源的。因此，证明过程只有在请求序号可以被某个常数（比如100）整除的时候才会周期性地进行。我们将这些请求执行后得到的状态称作 检查点（checkpoint） ，并且将具有证明的检查点称作 稳定检查点（stable checkpoint） 。
上述情况是理想情况，实际上当副本节点i向其他节点发出checkpoint消息之后，其他节点还没有完成K条请求的相互共识，所以不会立即对i的请求作出响应。其他节点会按照自己的处理步骤和顺序，向前行进和共识。但是此时i发出的checkpoint没有形成stable，为了防止i太快，超过自己太多，于是被便会设置一个高水位H=h+L，其中L就是我们指定允许的高度差，等于checkpoint周期处理数K的整数倍，可以设置为L=2K。当副本节点i处理请求超过高水位H时，副本节点即使接受到请求也会视为非法请求。等待stable checkpoint发生变化，再继续向前推进处理。
如果主节点作恶，它可能会给不同的请求编上相同的序号，或者不去分配序号，或者让相邻请求的序号不连续。备份节点（备份主节点）应当有职责来主动检查这些序号的合法性。如果主节点掉线或者作恶不广播客户端的请求，客户端设置超时机制，超时的话，向所有副本节点广播请求消息。副本节点检测出主节点或者下线，发起view change流程。
我们在上面讲到，当网络中有F台有问题的计算机时，至少需要3F+1台计算机才能保证一致性问题的解决，我们在这里讨论一下原因。
我们可以考虑：由于有F个节点为故障或被攻击的节点，故我们只能从N-F个节点中进行判断。但是由于异步传输，故当收到N-F个消息后，并不能确定后面是否有新的消息。（有可能是目前收到的N-F个节点的消息中存在被攻击的节点发来的消息，而好的节点的消息由于异步传输还没有被收到。）
我们考虑最坏的情况，即剩下F个都是好的节点，收到的中有F个被攻击的节点，故我们需要使得收到的中好节点的数量 (N-F)-F 大于被攻击节点的数量 F ，于是有 N-2FF ，即 N3F ，所以N的最小整数为 N=3F+1 。
pbft是需要参与认证的节点进行的。所以一个完整的共识算法包括DPOS+PBFT。其速度是可以达到1500tps左右的。
参考文献：
Practical Byzantine Fault Tolerance
Miguel Castro and Barbara Liskov Laboratory for Computer Science, Massachusetts Institute of Technology, 545 Technology Square, Cambridge, MA 02139 castro,liskov @lcs .mit.edu
部分论文翻译
拜占庭问题与共识算法
“拜占庭将军问题”（Byzantine Generals Problem）是一个经典难题，这个难题是这样描述的：拜占庭是东罗马帝国的首都，它的军队分成多个师，每个师都由一个将军统领。这些将军通过信使进行交流，来达成一个共同作战方案，有些将军可能是叛徒，想故意破坏这个过程，这会造成那些忠诚的将军也无法达成一个统一的作战计划。这个难题在于如何让那些忠诚的将军在这样的情况下达成统一作战方案，而避免那些叛徒对作战方案的误导。
在点对点、分布式的区块链中，常常用拜占庭问题来比喻节点如何达成共识的问题。将军即对应着一个个节点，达成统一作战方案即达成共识，正确的打包与验证区块数据，防止恶意节点（叛徒将军）破坏区块链的运行。
顾名思义，就是能够解决拜占庭问题，使各个节点达成共识，解决共识问题的各种机制也被称为共识算法。在各种各样的共识算法中，又一直存在一个「不可能三角」的难题，这三角是指“安全性”、“去中心化”和“速度”，也就是说难以同时保证速度、安全性和去中心化程度，三者之间往往会顾此失彼。
现在各种共识算法算起来有好几十种，计算机界也一直处于研究阶段，并没有说哪种算法已经完美。
下面盘点一下讲解pBET和POW两种算法，以及它们的“安全性”、“去中心化”和“速度”如何。
实用拜占庭容错是一种较早的共识算法。pBFT的一个原则，就是少数服从多数。节点通过在相互传递有关决策的消息，谁的决策赞同的人数多，就采用谁的。所以在这个系统中，安全性随着诚实节点的数量而增加。诚实节点同意正确的决策，拒绝恶意节点的错误决策，只要恶意节点的数量少于总数的1/3，就能保证达成共识。
达成共识可以简化为四步：
pBFT 使用投票机制以循环方式选举领导节点。
领导者发起决策并将其广播给辅助节点。
所有节点，包括领导节点和辅助节点，都发送响应。
当 ⅔ + 1 个节点发送相同的响应时，该响应被认为是有效的。
如果领导者有恶意行为，它可以被大多数节点删除。
按少数服从多数的原则。那按理来说，只要恶意节点的数量少于1/2就够了啊，那么为什么PBFT算法的容错数量要满足恶意节点的数量少于总数的1/3呢？
因为 PBFT 算法的除了需要支持容错故障节点之外，还需要支持容错作恶节点。假设集群节点数为 N，有问题的节点为 f。有问题的节点中，可以既是故障节点，也可以是作恶节点，或者只是故障节点或者只是作恶节点。那么会产生以下两种极端情况：
（1）这f 个有问题节点既是故障节点，又是作恶节点，那么根据少数服从多数的原则，集群里正常节点只需要比f个节点再多一个节点，即 f+1 个节点，正确节点的数量就会比故障节点数量多，那么集群就能达成共识，即总节点数为f+(f+1)=n，也就是说这种情况支持的最大容错节点数量是 (n-1)/2。
（2）故障节点和作恶节点都是不同的节点。那么就会有 f 个作恶节点和 f 个故障节点，当发现节点是作恶节点后，会被集群排除在外，剩下 f 个故障节点，那么根据少数服从多数的原则，集群里正常节点只需要比f个节点再多一个节点，即 f+1 个节点，确节点的数量就会比故障节点数量多，那么集群就能达成共识。所以，所有类型的节点数量加起来就是 f+1 个正常节点，f个故障节点和f个作恶节点，即 3f+1=n。
结合上述两种情况，因此PBFT算法支持的最大容错节点数量是(n-1)/3，即少于1/3。
pBFT的优缺点
pBFT 系统不需要高计算资源或大量能源来运行。pBFT 在节点少的时候可以快速达成共识，因为所有节点都在不断地相互通信。一旦节点就决策达成一致，交易就完成了。
然而，pBFT的缺点也很明显：频繁的通信使它只能在节点数量有限的网络中正常工作。随着每个新节点加入网络，通信开销呈指数增长，响应所需的时间也随之增加。
pBFT 网络也容易受到女巫(Sybil)攻击，女巫就是恶意黑客制造的不同节点，黑客可以控制多个节点，使其超过1/3，那系统将无法达成正确的共识。
从不可能三角的角度来看，由此可见pBFT在节点少的时候速度快，但安全性差，去中心化低；节点多了又会导致速度很慢。
中本聪设计了POW共识机制来解决上面pBFT这个经典共识的可扩展性问题。
上面说到，pBFT通过不断广播然后计算节点的消息数，时间花费过长。POW是怎么做的：我不要计算节点数是否超过2/3，我直接选一个节点，按它的决策，其他节点全部同步它的决策。这样就省去在全节点通信然后计算节点数的费时操作。
那么，对于哪个节点来打包区块，那就很重要，万一是恶意节点呢？必须对打包的节点进行要求，哪个节点有权力进行打包呢？那就是解决复杂的数学问题，俗称挖kuang。节点必须花费大量算力和电费来争取某次打包区块的权力。这样的成本就限制了黑客的女巫攻击。
如果打包区块的权力真的被黑客抢到了，那可能会有什么问题？
（1）窃取冰糖橙
黑客能够窃取属于另一个用户，不受她控制的地址里的冰糖橙吗？答案是否定的。即使这一轮是由黑客打包区块链上的下一个区块，她也不可能窃取别人的比特币。这么做的话，黑客需要发起一笔有效的交易来转移比特币到自己的地址。这就要求黑客伪造比特币拥有者的签名，然而如果数字签名机制是安全的，她是无法办到的。只要背后的密码学基础是牢靠的，她就无法轻易窃取比特币。
（2）拒绝服务攻击
让我们来考虑另一种攻击。假设黑客不喜欢叫鲍勃的某个用户，黑客可以决定她不把鲍勃发起的任何交易放进她所提议的区块里。换言之，她拒绝提供服务给鲍勃。尽管这是黑客可以开展的有效的攻击，但幸好这不过是个小问题。如果鲍勃的交易没有被放进黑客所打包的下一个区块，鲍勃只要等到下一个诚实节点发起区块的时候，他的交易记录就会被放进这个区块里。所以这其实也不算是一个有效的攻击。
也就是说，黑客花费重大成本取得的打包，但并不能起到有效的攻击。由于对恶意节点进行惩罚、对诚实节点进行奖励这样的机制下，共识就达成了。
尽管有所改进，POW也引入了其他问题。工作量证明需要所有节点解决复杂的数学问题，这会消耗大量的能源，就是大家所熟知的挖kuang耗费电力。并且解决复杂的数学问题的时间也要求不短，10分钟左右。
从不可能三角的角度来看，POW去中心化高，安全性高，但速度还是慢，但至少已经不会像pBFT那样由于节点多导致花费时间呈指数增长。
共识算法各式各样，冰糖橙的POW并不是真正去解决分布式共识问题，它不能完美的套用到其他场景。但它在货币系统的这个特定场景下解决了冰糖橙的共识问题。POW在冰糖橙里运行得非常好。
拜占庭共识算法RBFT：Redundant Byzantine Fault Tolerance
最近在研究拜占庭共识，做个记录吧，有些可能也没理解透。
RBFT : Redundant Byzantine Fault Tolerance
论文地址：
提出其他已有的BFT算法（prime、Aardvark、Spinning）其实并不能真正的进行拜占庭容错，主要是由于存在一个“primary”用来排序的。如果primary作恶，整个系统的性能会显著下降而且不会被发现。而RBFT则提出了新的模式：采用多核机机器并行执行多个PBFT的协议实例，只有master实例的结果会被真正执行，每个协议实例都会被监控其性能并与master实例比较，如果master的性能不行，则会认为此master的primary节点为坏节点并发起替换流程。据测算RBFT在存在BFT攻击时的性能下降最大为3%，而其他的协议为：Prime(78%)、Aardvark(87%)、Spinning(99%)。
综述：
具体步骤：
1、客户端吧请求发送到所有节点
请求格式如下：o:请求操作，rid：请求标识符，c:client
RBFT提供一个监控机制来发现master实例是否坏掉了。
每个节点为每个实例维护一个计数器（一共f+1个），用来记录此实例已经排序的请求数（也就是说收到2f+1个COMMIT消息的请求数）。节点会使用这些计数器周期性的计算每个实例的吞吐量并更新计数器。以下一些情况master会认为坏掉了触发协议实例变更：
1、master的吞吐量比backup的平均吞吐量低达到一定阈值。阈值是根据无拜占庭错误和有拜占庭错误的吞吐量差异设定的。
2、监控程序还监控排序时间，此机制为了保证master对于所有的client处理都是公平的。设定了每个请求的最大处理时间和client在不同实例里处理的时间差值。如果请求超过最大处理时间或者某个client在不同的实例里处理的时间差异过大也会触发协议变更
变更坏掉的primary。由于每个节点最多是一个实例的primary所以要动就是要所有primary全动。
每个节点维护一个计数器来记录每个实例的变更信息。如果节点发现需要变更primary则会发送INSTANCE CHANGE消息给所有的节点，MAC认证。节点接收到传来的INSTANCE CHANGE消息后验证MAC，然后跟自身的计数器比对，如果自身的更大，则忽略，如果传来的更大则查看自己是否也需要传播INSTANCE CHANGE消息（也是比较master和backup的性能），如果收到2f+1个有效的INSTANCE CHANGE消息则计数器加1然后启动view change流程（就是改primary，PBFT也是）。此后每个实例的primary都得到了更新，当然也包括master 的。（更新策略如果又换到了坏的呢？那会触发再次更新。。 前面提到的直接换最好的backup为master可能会更好点）
f个node是坏的，所以运行在此node里的所有实例都是坏的，所有的client都是坏的。
master实例运行的primary的node是好的:
此时：坏节点的目标是尽可能降低master实例的性能而不触发协议变更（why要不触发协议变更？: 论文里有证明，当primay of master为好节点时不会触发，主要是master的吞吐量比backup的平均吞吐量低达到一定阈值的这个阈值是不是随意定的是根据理论算出来的）。
方式：
master实例运行的primary的node是坏的:
此时：坏节点的目标是尽可能的降低backup实例的性能，这样就可以留给坏的primary富裕的空间来降低master的性能而不被发现（怎么定义发现？）。
方式：
