主页 > imtoken新版本 > 共识机制基础知识
共识机制基础知识
什么是共识机制？
区块链与比特币一起诞生，是比特币的基础技术架构。 区块链可以理解为基于互联网的去中心化记账系统。
像比特币这样的去中心化数字货币系统需要区块链来保证每个诚实节点在没有中心节点的情况下记账的一致性。
因此，区块链技术的核心是一种共识机制，在没有中央控制的情况下，没有互信基础的个人之间就交易的合法性达成共识。
为什么区块链需要共识机制？
在分布式系统中，多台主机通过异步通信形成一个网络集群。 在这样的异步系统中，需要在主机之间进行状态复制，以保证每台主机达成一致的状态共识。
在异步系统中，可能存在无法通信的故障主机，主机的性能可能下降，网络可能拥塞，这可能导致错误消息在系统内传播。 因此，需要在默认不可靠的异步网络中定义一个容错协议，以保证每台主机达成安全可靠的状态共识。
利用区块链构建基于互联网的去中心化账本，首要解决的问题是如何实现账本数据在不同账本节点上的一致性和正确性。
这就需要借鉴现有的分布式系统状态共识算法，确定网络中记账节点的选择机制，以及如何保证账本数据在全网形成正确一致的共识。
算法假设
在实践中，基于不同的假设设计了许多不同的共识算法。 这些算法中的每一个都有优点和局限性。 该算法的假设如下：
1）故障模型：非拜占庭故障/拜占庭故障。
2）通讯类型：同步/异步。
3）通信网络连接数：节点间直接连接数。
4）信息发送者身份：实名/匿名。
5) 通信信道稳定性：信道可靠/不可靠。
6) 消息真实性：认证消息/非认证消息。
在区块链网络中，由于应用场景不同，设计目标不同，不同的区块链系统采用不同的共识算法。
一般来说，在私有链和联盟链的情况下，对一致性和正确性有很强的要求。 一般来说，应该采用一致性强的共识算法。 在公链的情况下，通常不可能做到100%的一致性和正确性，通常采用最终一致性（Eventual Consistency）的共识算法。
目前区块链共识机制主要有四种：PoW、PoS、DPoS、分布式共识算法PoW
PoW（Proof of Work），和比特币一样，是一种挖矿机制，矿工将网络中尚未记录的现有交易打包成一个区块，然后不断遍历，试图找到一个随机数，让新的区块加入随机数的哈希值满足一定的难度条件，比如前10位为0。
找到一个满足条件的随机数，就相当于确定了区块链的最新区块，也相当于获得了区块链的本轮记账权。
矿工在网络中广播满足挖矿难度条件的区块。 在验证区块满足挖矿难度条件，区块中的交易数据符合协议规范后，将区块相互链接。 到自己版本的区块链，从而形成全网对当前网络状态的共识。
比特币和以太坊都是基于 PoW 的共识机制。
优势：
完全去中心化，节点自由进出，避免了建立和维护中心化信用机构的成本。
只要网络破坏者的算力不超过全网总算力的50%，网络的交易状态就可以达成共识。
缺点：
目前，比特币挖矿造成了大量的资源浪费。
挖矿激励机制也造成矿池算力高度集中，背离了去中心化设计的初衷。
更大的问题是PoW机制的共识需要很长时间才能达成共识，每秒最多只能做7笔交易，不适合商业应用。
权益证明
PoS权益证明需要节点提供分布式共识机制，持有一定数量的代币凭证，以获得竞争区块链的记账权。
如果单纯由代币余额决定记账人，富人胜出，会导致记账权中心化，降低共识的公平性。 因此，不同的PoS机制在权益证明的基础上采用不同的方式增加记账。 权重随机化以避免中心化。
比如在PeerCoin PoS机制中，链龄最长的比特币获得记账权的几率更大。 NXT 和 Blackcoin 使用一个公式来预测下一个记账节点。 您拥有的代币越多，被选为记账节点的概率就越高。
以太坊将从目前的 PoW 机制切换到 PoS 机制。 从目前看到的信息来看以太坊支持pow共识算法吗，以太坊的PoS机制会通过节点下注来押注下一个区块。 获胜者将从以太坊中扣除以太坊支持pow共识算法吗，以就下一个区块达成共识。
优势：
在一定程度上缩短了达成共识的时间，减少了 PoW 机制的资源浪费。
缺点：
破坏者进行网络攻击的成本很低，网络的安全性有待验证。
拥有大量代币的节点有更大的机会获得记账权，这将使网络的共识被少数富裕账户所支配，从而失去公平性。
权益证明
DPoS（Delegated Proof of Share）机制，类似于董事会投票。
bitshares和steem采用的DPoS机制是股东投票选出一定数量的见证人，每个见证人有两秒的授权时间依次生成区块。 如果见证人无法生成区块，则将区块生成权交给下一个时间片对应的见证人。
利益相关者可以随时投票更换这些见证人。 DPoS 的这种设计使得块生成更快、更节能。
优势：
大幅减少参与验证和记账节点数量，可实现秒级共识验证。
缺点：
选举固定数量的见证人作为会计候选人可能不适合完全去中心化的场景。
在网络节点数量很少的情况下，民选证人的代表性并不强。
以上三种算法多用于公链。
分布式共识算法
分布式共识算法是基于传统的分布式共识技术。 其中又分为解决拜占庭一般问题的拜占庭容错算法，如PBFT。
此外，解决非拜占庭问题的分布式共识算法（Pasox、Raft）是目前联盟链和私有链场景中常用的共识机制。
拜占庭问题讨论的是允许少数节点作恶（消息可能被伪造）场景下的共识达成问题。 拜占庭算法谈论最坏情况的保证。
Paxos问题是指分布式系统存在故障，但没有恶意节点（没有伪造消息，但可能丢失或重复）场景下的一致性问题。
优点：实现秒级快速共识机制，保证一致性。
缺点：去中心化程度不如公链上的共识机制； 更适合多方参与的多中心商业模式。
PBFT：Practical Byzantine Fault Tolerance，实用拜占庭容错
它在保证活跃性和安全性的前提下提供(n-1)/3的容错能力。 在分布式计算中，不同的计算机试图通过消息交换达成共识； 但有时，系统上的协调计算机（Coordinator/Commander）或成员计算机（Member/Lieutanent）可能会由于系统错误而交换错误消息，从而影响最终的系统一致性。
拜占庭将军问题是根据错误计算机的数量，寻找可能的解决方案，不能找到绝对的答案，只能用来验证一种机制的有效性。
拜占庭问题的可能解决方案是：
在 N ≥ 3F + 1 的情况下，一致性是可以解决的。 其中，N为计算机总数，F为出现问题的计算机总数。 计算机之间交换信息后，每台计算机列出所有获得的信息，并取大部分结果作为解决方案。
优势：
系统的运行可以脱离硬币的存在。 pbft算法共识是每个节点由业务参与者或监管者组成，安全性和稳定性由业务利益相关者保证。
共识延迟在2~5秒左右，基本满足商业实时处理的要求。
共识高效，能够满足高频交易量的需求。
缺点：
当1/3或更多记账员停止工作时，系统将无法提供服务。 当1/3或更多记账人联手作恶，其他所有记账人分成两个网络孤岛时，恶意记账人可以导致系统分叉，但会留下密码学证据。 帕克索斯
1990年Leslie Lamport提出的Paxos共识算法，从工程角度实现了最大化一致性（有极小概率达不到一致性）的机制。 Paxos广泛应用于Chubby、ZooKeeper等系统，Leslie Lamport也因此获得2013年图灵奖。
故事背景是古希腊帕克森岛上的多位法官如何在一个大厅内对一项议案进行表决，并得出统一的结果。 他们之间通过服务人员传递纸条，但法官可能会离开或进入大厅，而服务人员可能会溜走睡觉。
Paxos 是第一个经过验证的共识算法，其原理基于两阶段提交和扩展。
作为当前共识算法设计的鼻祖，以原论文难度大（算法本身并不复杂）着称。 在算法中，节点分为三种类型：
proposer：提出一个提案，等待大家通过后作为closed case；
acceptor：负责对提案进行投票；
学习者：获知案件结果并与之统一，不参与表决过程。
并满足三个约束要求：
该决议（价值）只能由提案人提出的提案最终通过；
在一个执行实例中，只有一个最终决议被通过（选择），这意味着多数接受（accept）的结果才能成为决议；
学习者只能获得选定的决议。
算法本身在语言描述上极其简洁：
阶段1
提议者向网络中超过一半的接受者发送准备消息；
接受者通常会回复承诺消息。
第二阶段
当有足够多的接受者回复承诺消息时，提议者发送接受消息；
在正常情况下，接受者回复一个已接受的消息。
基本流程包括提案人提出提案，首先征得大多数接受者的支持，当超过一半的接受者支持时，将最终结果发送给大家确认。 一个潜在的问题是proposer在这个过程中失败了，可以通过超时机制来解决。 在极其巧合的情况下，每次新一轮提案的提议者恰好失败，系统将永远无法达成共识（概率很小）。
Paxos可以保证系统在超过半数的正常节点存在时能够达成共识。
单一提议者
如果系统只限制特定的节点作为提议者，那么肯定可以达成共识（只有一种方案，要么达成，要么失败）。
但是一旦提议者失败，系统就无法工作。
多个提议者
问题一下子变得复杂起来。
一种情况是同一个时间片（比如一个提案周期）只有一个proposer。 这就需要设计一种机制来保证proposer的正确生成，比如按照时间，顺序，或者大家猜（一个数字进行比较）。 考虑到分布式系统要处理的工作量很大，这个过程必须尽可能高效，设计一个满足这个条件的机制是非常困难的。
另一种情况是允许两个提议者出现在同一个时间段。 那么同一个节点可能会收到两个proposal，如何区分呢？ 自然，提案需要携带不同的序列号。 节点需要根据提案序号判断接受哪一个。 例如，接受一个序号较大的提案（这往往意味着接受一个新的提案，因为旧的提案人失败的概率更高）。
您如何为提案分配序列号？ 一种可能的解决方案是每个节点的提案编号区间相互隔离，互不冲突。 为了满足增量需求，时间戳可以作为高阶字段。
两阶段提交
提案人发出提案后，会收到一些反馈。 我这时候才知道，一个结果是我的提议被多数人接受，另一个结果是没有被接受。 如果不接受，好说，稍后再试。
即使有大多数人的接受反馈，也不能视为最终确认。 因为这些接收者自己并不知道，他们刚刚反馈的提案恰好是全局的绝大多数。
自然而然引入了一个新的阶段，即提议者在得到上一阶段的所有反馈后，判断该提议很可能被多数人接受，需要敲定。
在Paxos中，这两个阶段分别命名为prepare和commit。
准备阶段解决的是大家投票给哪个提案的问题，提交阶段解决的是最终价值的确认问题。
下面，我们简化认为较大的提案数量意味着较新的提案。
在准备阶段，比较简单。 多个提议者可以发送提议： ，接收者收到提议后返回收到的消息，只保留最新的提议。 如果收到一个小于当前保留的请求的提案编号，则将保留的提案返回给提案人，告诉它其他人已经发布了更新的提案。
在提交阶段，如果一个提议者在准备阶段收到了多数答复（意味着大多数人已经听到了它的请求，可能准备好进行最后的确认），它会再次发送确认消息。如果收到大部分答复再次，大家空着返回，带上原来的提案编号和内容； 如果返回中有更新的提案，则用更新的值替换提案
建议值。 如果您没有得到足够的答复，您需要重新提出请求。
如果接收者发现提案编号与他当前保留的编号一致，他将确认该提案。
筏
Raft 是 Paxos 的重新设计和实现。
Raft算法是Paxos算法的简化实现。
RAFT的核心思想很容易理解。 如果几个数据库的初始状态相同，只要后面的操作一致，就可以保证后面的数据是一致的。 因此，RAFT使用Log进行同步，将服务器分为Leader、Follower、Candidate三种角色，可以相互转换。
从广义上讲，RAFT分为两个过程：
选举 LeaderLeader 生成 Log 并与 Follower 同步 Headbeats
注意：这里的日志不是指日志消息，而是各种事件的记录。
选举领袖
Follower自增当前任期，转换为Candidate，给自己投票，并发起RequestVote RPC，等待以下三种情况发生；
Get more than half of the server's votes, win the election, and become the Leader
Another server wins the election and receives the corresponding heartbeat, becoming a Follower
The election timed out, no server won the election, the current term will be incremented, and the election will be re-initiated
同步日志
Leader接受客户端请求，Leader更新日志，向所有Follower发送Heatbeats同步日志。 所有 Follwers 都有一个 ElectionTimeout。 如果在ElectionTimeout时间内没有收到Leader的Headbeats，则认为Leader无效，重新选举Leader。
安全保证
日志的流向只是从Leader到Follower，Leader不能覆盖日志
不是最新的日志不能成为候选人
一个生动的演示动画：
dBFT：委托BFT授权拜占庭容错算法
小易采用的 dBFT 机制是按权益选择记账人，然后记账人通过拜占庭容错算法达成共识。
该算法在PBFT的基础上有以下改进：
将C/S架构的请求-响应模式改进为适合P2P网络的点对点节点模式；
将静态参与共识节点改进为可动态进入和退出的动态参与共识节点；
为共识参与节点的产生设计一套基于持股比例的投票机制，通过投票决定共识参与节点（记账节点）；
区块链引入数字证书，解决了投票中记账节点真实身份的认证问题。
优势：
专业簿记员；
可以容忍任何类型的错误；
多人共同完成记账，每个区块具有最终性，不会分叉；
算法的可靠性有严格的数学证明；
缺点：
当1/3以上的记账员停止工作时，系统将无法提供服务； 当1/3以上的记账人共同作案，其他所有记账人分成两个网络孤岛时，恶意记账人可以导致系统分叉，但会留下密码学证据；
综上所述，dBFT机制的核心点在于最大程度保证系统的最终性，从而使区块链能够应用于真实的金融应用场景。
POOL验证池
基于传统的分布式一致性技术，加上数据校验机制。
优势：
无需代币即可工作，基于成熟的分布式共识算法（Pasox、Raft）实现秒级共识验证。
缺点：
去中心化程度不如比特币； 更适合多方参与的多中心商业模式。
参考
原文：区块链技术指南
