知识拓展：区块链技术之共识算法-技术圈

大家好，我是牛牛！

相信大家对比特币、NFT或多或少有所耳闻吧。比特币、NFT的底层，其实都是区块链技术。

在区块链技术中，最核心的部分，就是共识。共识在私有环境、联盟环境、公开环境下会有不同的挑战与应对方式。

牛牛以前因为工作原因，就对私有环境下的共识算法有了解。

近两年区块链岗位增多了，学习相关的知识，性价比也更高了，牛牛就顺势研究了共识在各种场景下都是怎么实现的，今天就来给大家分享一波。

读完这篇文章，相信你可以对共识有个初步的了解。

共识是什么？

望文生义，所谓共识，就是共同的认识，也就是达成一致。

开会表决出的结果是共识，领导的权威是共识，钻石的价值是共识。更简单直接一点，如果我们都认为猫咪很可爱，那么在这件事情上，我们就达成共识。

可以说，人类的发展，就是在互相认可、达成共识中进行的。

从单机到集群

从单机到集群，通常有两种原因：

1.性能不足。单机处理的能力达到了上限，此时就需要多台机器一起提供服务，这种情况下，每台机器就相当于一个分片，各司其职，处理好自己的那部分。

2.可靠性不足。单机存在风险和隐患，所以需要扩展出多个副本，一起协作，完成使命。这种情况下，多个节点之间，怎么交流，数据怎么保持一致，就是值得考虑的。

由于性能不足这部分更像分工合作，基本不涉及共识。所以我们主要聚焦于可靠性，看看如何通过共识，解决分片一致性问题。

多副本共识

从一个分片到多个分片，就会涉及到数据的共识。我们设想一下，如果在现实中，两个人的信息要达成一致，有哪些手段呢？

最简单的一种，就是信任，即我的信息完全从你那里得知，你说啥，我认可啥。平常我们的数据库容灾，就是这样的。

再者就是协商，惯例是少数服从多数，可以用投票决定。

听起来是不是很简单，但实际做起来却不容易。我们的生产环境中，可能会遇到一些很棘手的挑战。

接下来，我们就来谈谈从私有环境、联盟环境，最后到公有环境，由浅至深，会面临哪些挑战，应对的方法又是怎么样的。

挑战一：系统异常

做后台开发的都知道，异常是不可避免的，我们总会遇到系统出现网络、磁盘故障、服务器宕机这类问题，这些都属于Crash Fault，而我们需要做到的，就是Crash Fault Tolerance，即在故障情况下也能正常工作。

解决方案：Crash Fault Tolerance

经典的CFT算法包括Paxos、Raft等，这类算法性能较好、处理速度较快、可以容忍不超过一半的故障节点。

Paxos算法是Leslie Lamport于1990年提出的一种基于消息传递且具有高度容错特性的共识算法。

它描述的是这样一个场景：在一座叫Paxos的小岛，议会决议岛上的所有事务。议会成员的数量是确定的，每个提案都需要超过半数的议员同意才能生效。

议员们通过信使传递消息来对议案进行表决。但议员可能离开，信使可能走丢，甚至同一封信投递好几次。

在这样的条件下，我们要怎么达成共识呢？

Paxos算法将议员的角色分为Proposers、Acceptors和Learners。由proposers提出提案，通过一系列复杂的交互，最终得到共识。

这里先不做赘述，大家只需要知道Paxos特点是晦涩复杂，难理解。

Raft算法则起源于2013年斯坦福Diego Ongaro和John Ousterhout的一篇论文。

他们觉得Paxos太难理解了，都不知道怎么向学生讲解，于是设计出了Raft这个既便于学生学习又容易上手实现的一致性算法。

Raft的数据一致性等价于Multi Paxos，可以用于取代Paxos，并且证明可以提供与Paxos相同的容错性以及性能。

Raft算法是基于日志复制的，它将节点分为Leader、Follower、Cadidate三种，由Leader将请求写入日志，再通知到其它节点进行复制，以达到状态的最终一致，Cadidate则是Follower进取成为Leader的中间状态。

Raft协议设计的首要目标是易于理解，所以采用了分解法：Raft流程可分解为选主、日志复制、安全性和存储回收，能为在计算机集群之间部署有限状态机提供一种通用方法，并确保集群内的任意节点在某种状态转换上保持一致。

关于RAFT，我们目前只需要记住几点：

1.它将复杂问题转变为几个简单的问题；

2.采用日志复制算法；

3.简单清晰。

挑战二：害群之马

解决了CFT问题，在相对安全的网络环境是可以高枕无忧了。注意，我们说的是相对安全，比如平常在公司的内网环境中。

什么时候不安全呢？

集群由几个组织下的不同机房管理，我们把这个环境称为联盟环境，这时候就可能会有作恶节点出现。

这些作恶节点轻则会捣乱，不让大家达成共识，重则发布恶意的虚假信息造成危害。

也就是说，如果群众里面有坏人，单纯的CFT算法就cover不住了。

这种需要考虑恶意节点的场景，就叫做拜占庭问题。

之前提到的RAFT和PAXOS，都不能解决拜占庭问题。

解决方案：Byzantine Fault Tolerance

针对拜占庭问题，我们就需要专门的拜占庭算法。

有小伙伴肯定会问，为什么叫拜占庭呢？

如果我告诉你拜占庭算法最早也是由Leslie Lamport解决的，那你一定已经明白了，没错，这其实跟Paxos一样，都是Leslie Lamport借由一个著名的城市编造一个故事，给我们描述一类问题。

拜占庭故事是这样的：拜占庭帝国的军队都驻扎在敌城外，相隔很远，每个师都由各自的将军指挥。将军们只能通过信使相互沟通。

在战争时期，他们必须制定一个共同的行动计划，如进攻(Attack)或者撤退(Retreat)，且只有当半数以上的将军共同发起进攻时才能取得胜利。

然而, 其中一些将军可能是叛徒，试图阻止忠诚的将军达成一致的行动计划。更糟糕的是，负责消息传递的信使也可能是叛徒，他们可能篡改或伪造消息，也可能使消息丢失。

这样我们又怎么样才能达成一致，取得战争的胜利呢？

最知名也是最常见的解决方案是PBFT，即实用拜占庭容错算法，这种算法通过三阶段的提交，以反复进行阶段确认的做法，可以保证在恶意节点不超过总数三分之一情况下，系统能良好正确的运行下去。

实用拜占庭算法比起经典的拜占庭算法，将性能从指数级降低到了多项式级，做了很大程度的优化，这才有了在生产中实践的可能。

但是也有一些限制，比如需要节点认证，以及节点数量也不建议超过100。

这里做个了解就好，也不过多赘述了。

挑战三：海量节点

实用拜占庭容错算法，节点通常是固定的，适用于联盟场景。但在公有场景下，节点需要能自由增加减少，比如比特币。

同时出于性能考虑，BFT的节点通常建议不超过100个，而比特币的节点遍布全世界，多不胜数，显然也是满足不了的。

针对这种公链场景，又该如何达成共识呢？

解决方案：POW&POS

方法总比问题多，公链也有公链的共识算法，最出名的就是POW和POS。

POW（工作量证明）是比特币系统采用的共识算法。

比特币的共识是通过10分钟一轮的算力竞赛实现的，竞赛的胜利者，就获得一次记账的权力，并向其他节点同步新增账本信息。

当然，其它节点会做验证，如果记账节点有任何的作弊行为，都会导致网络的节点验证不通过，直接丢弃其打包的区块，这个区块就无法记录到总账本中，作弊的节点耗费的成本就白费了。

由于有这样巨大的挖矿成本，使得矿工自觉自愿地遵守比特币系统的共识协议，也就确保了整个系统的安全。

说白了，工作量证明是代价驱动。我都付出了这么大的代价了，如果不能收获奖励，则损失巨大，所以我也就没有了作弊的动机。比特币最牛逼的地方，就是采取了经济手段，实现共识。

POS（权益证明）则走向了另一条路：记账权取决于积分，积分由币量和币龄综合决定。简单来说，你拥有的币越多，币龄越长，就有越大的概率获得记账权。

POS的优点在于矿工不需要去拼算力，因而不会浪费太多算力，性能也高一些。

缺点在于拥有代币的大户可以坐享其成，而且所有参与者可以持币拿利息。卖币的人也会少了，大家想着存着币拿利息，也不利于流动性。并且容易产生马太效应，让富人越富，穷人越穷，相对来说，POS没有POW公平。

除了POW、POS，公链上还有DPOS、POA、POL等算法，感兴趣的小伙伴可以去了解一下。

总结

共识是分布式领域极具魅力的一个话题，也是区块链的核心内容。

本次给大家介绍了私有环境的Raft、Paxos算法，联盟环境的PBFT算法，以及公链情况下的POW、POS算法。

后续牛牛也会选择其中比较有代表性的算法，单独写文章进行详细分析。

点击下方链接查看往期精彩文章

END

关注公众号，免费领取学习资料

你好，我是牛牛，普通二本毕业。

本科进腾讯，去过外企，肝过头条。

目前回腾讯担任高级工程师。

想来腾讯的朋友，可以找我内推哦！

点个“赞”和“在看”鼓励一下嘛~