区块链拜占庭算法 区块链的定义中,拜占庭

本篇文章主要给网友们分享区块链拜占庭算法的知识，其中更加会对区块链的定义中,拜占庭进行更多的解释，如果能碰巧解决你现在面临的问题，记得关注本站！

拜占庭问题与共识算法

“拜占庭将军问题”（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在冰糖橙里运行得非常好。

拜占庭容错和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

部分论文翻译

区块链笔记——PBFT

PBFT是实用拜占庭容错的简称，是解决拜占庭将军问题的一种方案。比起最开始的BFT算法，PBFT额外要求网络封闭，即节点数目确定并提前互通，但将复杂度从指数级降低到多项式级，使得BFT系列算法真正具有可行性。

与POW、POS等大家耳熟能详的共识不同，BFT系列的共识不需要“Proof”，亦即不需要节点投入算力或其他资源来确权，因此不需要代币激励便可完成共识。缺点是原始的BFT效率太低，只能存在于理论而无法应用。而改进的PBFT虽然效率大大提高，却对节点数量和状态提出了要求，导致合格的记帐节点太少，并且也只能维持在少数，过多的节点会拖慢网络速度。因此PBFT更多是用在联盟链和私链上。公链也有应用，例如NEO，便是采用了PBFT算法。

拜占庭将军问题的实质是在恶劣的通讯环境中，如何使各参与方达成一致意见。POW和POS等共识要求参与方投入成本，争夺唯一的发言权。在某一段时间内只有唯一的发言人，自然只会有一个意见，从而达成共识。PBFT采取不同的思路，要求各参与方相互发送及验证彼此的信息，最终采用多数原则达成共识。

PBFT能够以一种低成本的方式实现节点间共识，其理念其实相当贴近我们的生活习惯。例如在老师布置作业后，同学们总要互相问问确认一下，才放心地把今天的作业记到本子上。当然实现上还有很多细节，保证各节点的平等关系。在节点数目不多的时候，节点之间实现相互通信的成本并不高，节点之间可以快速发送确认。但节点数目增长却会带来整体性能的下降。PBFT可以容忍的坏节点数量不多于总数的三分之一，如果节点损坏率比较固定，提高总节点数量虽然能使系统获得更好的冗余，却会大大增加通讯量，造成效率下降。加上PBFT没有激励机制，其适合联盟链和私链场景。作为公链不可避免地节点数量太少，分布过分集中，例如NEO只有七个节点。

PBFT要求坏节点数量f=(n-1)/3，这里n是总节点数。只要f满足这个条件，共识总是可以达成。为什么f要满足这个条件？简单来说，假设网络中存在恶意节点联盟，其控制了数量为f的节点，这些节点可以故意发布错误的信息。此时网络中正常节点数量为n-f个。将这n-f个节点分为两部分，各自包含一部分节点。对于任一部分正常节点来说，只要恶意节点数f大于自身节点数，同时大于剩余的正常节点数，这部分正常节点便会与恶意节点联盟达成共识。此时只要恶意节点联盟先后向两部分正常节点发送不同的共识信息，便可造成网络分叉。因此要保证网络运行，对于每一部分正常节点来说，网络中恶意节点数量不能同时大于自身节点数和网络剩余正常节点数。代入计算便得到f=(n-1)/3。

区块链有几种共识算法？

Ripple Consensus（瑞波共识算法）

使一组节点能够基于特殊节点列表达成共识。初始特殊节点列表就像一个俱乐部区块链拜占庭算法，要接纳一个新成员，必须由51%区块链拜占庭算法的该俱乐部会员投票通过。共识遵循这核心成员的51%权力，外部人员则没有影响力。由于该俱乐部由“中心化”开始，它将一直是“中心化的”，而如果它开始腐化，股东们什么也做不区块链拜占庭算法了。

5、PBFT区块链拜占庭算法：Practical Byzantine Fault Tolerance（实用拜占庭容错算法）

PBFT是一种状态机副本复制算法，即服务作为状态机进行建模，状态机在分布式系统的不同节点进行副本复制。每个状态机的副本都保存了服务的状态，同时也实现了服务的操作。将所有的副本组成的集合使用大写字母R表示，使用0到|R|-1的整数表示每一个副本。为了描述方便，假设|R|=3f+1，这里f是有可能失效的副本的最大个数。尽管可以存在多于3f+1个副本，但是额外的副本除了降低性能之外不能提高可靠性。

PBFT算法主要特点如下：客户端向主节点发送请求调用服务操作区块链拜占庭算法；主节点通过广播将请求发送给其他副本；所有副本都执行请求并将结果发回客户端；客户端需要等待f+1个不同副本节点发回相同的结果，作为整个操作的最终结果。

写到这里，本文关于区块链拜占庭算法和区块链的定义中,拜占庭的介绍到此为止了，如果能碰巧解决你现在面临的问题，如果你还想更加了解这方面的信息，记得收藏关注本站。