区块链中不同共识算法介绍

1. 什么是共识算法

共识通常与一致性一词一起讨论。 严格来说，两者的含义并不完全相同。 一致性的含义比共识更广泛，在不同的场景（事务型数据库、分布式系统等）中有不同的含义。 具体在分布式系统的上下文中，一致性指的是多个副本的外部状态。 如前所述，顺序一致性和线性一致性描述了多个节点共同维护数据状态的能力。 而共识，特指在分布式系统中的多个节点之间就某一事项（如多个交易请求，谁先执行？）达成共识的过程。 因此，达成某种共识并不意味着一致性得到保证。 在实践中，要保证系统满足不同程度的一致性，往往需要通过共识算法来实现。

共识算法解决的是分布式系统对某个提案（Proposal）、大多数节点达成共识的过程。 提案在分布式系统中的含义非常广泛，比如多个事件发生的先后顺序、某个key对应的值、谁是主节点等。凡是可以达成一致的信息都可以认为是一个提议。 对于分布式系统，每个节点通常是相同的确定性状态机模型（也称为状态机复制问题，State-Machine Replication），从相同的初始状态接收相同的指令序列可以保证相同的结果状态。 因此，对于系统中的多个节点来说，最关键的是对多个事件的顺序进行约定，即排序。

2、区块链中的共识算法？

区块链是典型的分布式系统，具有去中心化的特点。 与阿里云等一般意义上的分布式系统相比，一些公链如BTC、ETH等也会面临拜占庭节点问题。 为了增加可信度，区块链系统中的所有节点共同维护同一个账本。 在以太坊中，由于所有节点都维护同一个账本，所以这里的共识算法需要对所有节点维护的账本达成共识。 如果没有共识算法，那么所有节点维护的账本就会不一致甚至维护自己的账本。 由于BTC、ETH等没有政府信用背书，它们是一种信任币，也就是信任他的人越多，它的价值就越大。 因此，如果没有共识算法来维护同一个账本，那么这个账本就没有说服力，这些币的价值实际上也就丢失了。 因此，共识算法是区块链的价值基础，加密算法是价值的保障，P2P技术是价值的传递。

3.设计共识算法时需要考虑的要点

在以太坊或比特币等公链场景下，面临以下问题。 1. 与内部集群相比，公链面向整个互联网的网络环境较差，主要表现在网络延迟大、丢包率高。 2、与集群服务器相比，公链节点非常不稳定，主要是用户随意退出加入、宕机等。 3.相对于集群，比如spark、Hadoop，往往有一个master节点来管理集群的运行。 区块链提倡去中心化，即所有节点都是平等的，即没有所谓的主节点管理整个分布式系统。 4、由于公链下所有节点都是平等的，因此存在拜占庭节点，主要表现在节点会进行某些恶意行为。 在分布式系统中，有一个CAP理论：该理论首先将分布式系统的三个特点总结如下：

一般来说比特币共识算法，分布式系统不能同时满足这三个条件。 对于公链来说，为了保证用户体验和易用性，往往满足AP，弱化C。 AP对应上面的1和2两个条件。那么在拜占庭节点存在的情况下如何保证弱一致性呢？

我们知道，在分布式系统中，要保证所有节点的账本都是一样的，前提是必须有一个唯一的账本。 如果达不到这个条件，那就有两个法令，就不用提共识了。 其次，如何保证账本是可信的。 如果不能满足这个条件，账本的价值就会丢失。 如果满足以上两个条件，那么就可以保证法令的前后一致和可信。 以太坊和比特币都使用 PoW 公式算法，这是一种相对简单但有效的方法。 首先，为了保证法令一致，即只有一个节点可以记账，我们需要找到一个选择记账节点的规则。 在PoW中，以算力为规则，即哪个节点的算力强，就选择这个节点作为记账节点，这种方式比较简单粗暴，但是也很有效，因为算力强不能虚拟化，是一种比较公平的方法。 那么，如何保证账本的可信度呢？ 首先，挖矿所需的哈希与当前挖出的区块的哈希有关，区块使用默克尔树和父区块哈希来保证区块一旦生成，就不能被修改。 所有节点收到记账节点发出的区块后，都可以快速验证，从而保证记账节点发出的区块的可信度。 当然，既然每个节点都可以作恶，那么你可以选择不信任一个合法的区块，但是由于账本是大家共同维护的，除非全网有超过51%的节点作恶，那么合法的区块就可能被拒绝加入账本，但作恶的成本会非常高，所以从博弈的角度来看，很少有人做这种零和博弈。

4. 主流共识算法

目前，除了 PoW 之外，还有很多其他的共识算法。 主流的共识算法包括PoS、DPoS、

PBFT、Paxos、Raft等这些共识算法在不同的场景下都是合理的。

1) 战俘

POW算法即工作量证明算法，适用于比特币、以太坊等公链场景。 它是一种简单粗暴的共识算法，但该算法是一种弱一致性算法，从性能的角度来看存在分歧。 健康）状况。 同时POW会浪费大量的算力，所以整个系统的效率比较低。 POW的过程可以理解为寻找一个nonce值来满足hash(block, nonce) v。即propose(t', v')中的v'=v。 当然，如果v为空，那就不冲突了，直接写v就可以了。

在第二阶段

阶段2，propose将v和rnd发送给acceptor，当acceptor收到后，如果rnd与acceptor相同

如果last_rnd不一致，请求将被拒绝，否则，将v写入本地，并将v标记为可接受值。 这里使用last_rnd==rnd来保证没有其他Proposer在这个过程中写值。 最后，通过以上两个阶段，可以在没有拜占庭节点的分布式环境下保证系统的一致性。

6) 木筏

Raft 是一种用于管理日志复制的共识算法。 它具有与Paxos相同的性能和功能，但其结构与Paxos不同； 这使得 Raft 更容易理解，也更容易构建实用的系统。 为了提高理解力，Raft将共识算法分为领导者选择（leader selection）、7日志复制（log replication）和安全（safety）等几个部分，它使用更强的一致性来减少必须考虑的状态. 从用户学习的结果来看，Raft 比 Paxos 更容易学习。 Raft 还包括一种动态更改集群成员身份的新机制，使用重叠多数来确保安全。

与Paxos相比，Raft有以下特点：

强领导：Raft 使用比其他算法更强的领导形式。 例如，日志条目仅从领导者发送到其他服务器。 这简化了日志复制的管理，并使 Raft 更容易理解。

Leader Selection：Raft 使用随机定时器来选择 Leader。 这种方法只是对所有算法都需要实现的心跳机制做了一点改动，它使得冲突的解决变得更加简单快捷。

Membership Change：Raft使用一种新的联合共识方式来调整集群中的成员关系。 在这种方法中比特币共识算法，大多数不同配置的机器在转换关系时会重叠。 这使集群能够在进行配置更改时继续运行。

4. 如何选择适合自己的共识算法

从面向场景的角度来看，paxos和raft无法处理拜占庭节点，因此这类共识算法更适合用于私有链等节点间信任度较高的场景。 但是，pbft 中节点的通信复杂度是 n^2。 因此，如果公链的节点数很大，pbft 的性能会很差。 因此，pbft更适合小规模、高性能要求、拜占庭节点的联盟链环境。 PoS、DPoS、PoW可以处理拜占庭节点，扩展性高，更适合公链场景。 不过个人认为PoS和DPoS并不是严格意义上的去中心化，其节点具有层次结构，因此在联盟链的设计中可以借鉴。 本文已由作者李星授权网易云社区发布。

免费领取验证码、内容安全、短信发送、直播点播体验包、云服务器等套餐

更多网易技术、产品、运营经验分享，请点击这里。