区块链解决了在不可信信道上传输可信信息、价值转移的问题，而共识机制解决了区块链如何在分布式场景下达成一致性的问题，奠定了比特币系统的安全性。
1.分布式一致性问题（共识算法）
1. 一致性问题（Consensus Problem）
一致（Agreement） :每个正确的执行过程应该在相同的值上达成一致；
完整（Integrity） :每个正确的执行过程最多只能决定一个值。如果它决定了某个值的话，这个值一定是被某个执行过程提出的；
终止（Termination） :所有的执行过程最终会做出一个决定；
正确（Validity） :如果所有正确的执行过程提出了相同的值V，那么所有正确的执行过程都会决定值V。
2. FLP不可能性（FLP impossibility）
实际的计算机集群中，可能会存在以下问题:
1.节点处理事务的能力不同，网络节点数据的吞吐量有差异
2.节点间通讯的信道可能不安全
3.可能会有作恶节点出现
4.当异步处理能力达到高度一致时，系统的可扩展性就会变差（容不下新节点的加入）。
FLP不可能性定理证明了在分布式情景下，无论任何算法，即使是只有一个进程挂掉，对于其他非失败进程，都存在着无法达成一致的可能。在假设网络可靠、计算节点只会因崩溃而失效的最小化异步模型系统中，仍然不存在一个可以解决一致性问题的确定性算法。
FLP是Fischer, Lynch，Patterson三位作者名字组合的简写，表明这定理是由它们三位发明的。
证明
更多参考
3. CAP定理
分布式计算系统不可能同时确保一致性、可用性和分区容忍性。
一致性（Consistency） :所有节点在同一时刻能够看到同样的数据，也即“强一致性”；
可用性（Availability） ：确保每个请求都可以收到确定其是否成功的响应；
分区容忍性（Partition tolerance） :因为网络故障导致的系统分区不影响系统正常运行。
这也就意味着，我们虽然不能使某个分布式场景同时满足三个性质，但可以使之同时满足三个中的两个。更进一步说，对于包含多个分布式场景的分布式系统，我们甚至可以在三个性质的程度上进行适当的权衡^footnote。
4. 拜占庭将军问题
（1）Byzantine Fault Tolerant 算法
面向拜占庭问题的容错算法，解决的是网络通信可靠，但节点可能故障情况下的一致性达成。
最早由 Castro 和 Liskov 在 1999 年提出的 Practical Byzantine Fault Tolerant（PBFT）是第一个得到广泛应用的 BFT 算法。只要系统中有三分之二的节点是正常工作的，则可以保证一致性。
PBFT 算法包括三个阶段来达成共识：Pre-Prepare、Prepare 和 Commit。
具体参考
PBFT优点：脱离了币的存在，币的存在及它的奖励机制会让区块链这一单一的世界穷者更穷，富者更富。
共识效率高，可实现高频交易。
缺点：当系统只剩下33%的节点运行时，系统会停止运行。
（2）PoW（Proof of Work）算法
一个是限制一段时间内整个网络中出现提案的个数（增加提案成本），另外一个是放宽对最终一致性确认的需求，约定好大家都确认并沿着已知最长的链进行拓宽。系统的最终确认是概率意义上的存在。这样，即便有人试图恶意破坏，也会付出很大的经济代价（付出超过系统一半的算力）。
后来的各种 PoX 系列算法，也都是沿着这个思路进行改进，采用经济上的惩罚来制约破坏者。
优点：
完全去中心化
节点自由进出，容易实现。
破坏系统花费的成本巨大
缺点：
对节点的性能网络环境要求高
无法达成最终一致性
浪费能源
（3）Paxos共识算法
1990 年由 Leslie Lamport 提出，是第一个被证明的共识算法，在工程角度实现了一种最大化保障分布式系统一致性（存在极小的概率无法实现一致）的机制。
算法中将节点分为三种类型：
proposer：提出一个提案，等待大家批准为结案。往往是客户端担任该角色
acceptor：负责对提案进行投票。往往是服务端担任该角色
learner：被告知结案结果，并与之统一，不参与投票过程。
算法需要满足 safety 和 liveness 两方面的约束要求（实际上这两个基础属性是大部分分布式算法都该考虑的）：
safety：保证决议结果是对的，无歧义的，不会出现错误情况。
liveness：保证决议过程能在有限时间内完成。
基本过程包括 proposer 提出提案，先争取大多数 acceptor 的支持，超过一半支持时，则发送结案结果给所有人进行确认。一个潜在的问题是 proposer 在此过程中出现故障，可以通过超时机制来解决。极为凑巧的情况下，每次新的一轮提案的 proposer 都恰好故障，系统则永远无法达成一致（概率很小）。
Paxos 能保证在超过50%的正常节点存在时，系统能达成共识。
（4）Raft算法
Raft 是对 Paxos 的重新设计和简化实现。
包括三种角色：leader、candiate 和 follower，其基本过程为：
Leader 选举：每个 candidate 随机经过一定时间都会提出选举方案，最近阶段中得票最多者被选为 leader；
同步 log：leader 会找到系统中 log 最新的记录，并强制所有的 follower 来刷新到这个记录；
具体参考
2. 共识模型
1. POW
工作量证明，Proof of Work，通过计算来猜测一个数值（nonce），得以解决规定的 hash 问题。
保证在一段时间内，系统中只能出现少数合法提案。
同时，这些少量的合法提案会在网络中进行广播，收到的用户进行验证后会基于它认为的最长链上继续难题的计算。
因此，系统中可能出现链的分叉（Fork），但最终会有一条链成为最长的链。
hash 问题具有不可逆的特点，因此，目前除了暴力计算外，还没有有效的算法进行解决。反之，如果获得符合要求的 nonce，则说明在概率上是付出了对应的算力。谁的算力多，谁最先解决问题的概率就越大。当掌握超过全网一半算力时，从概率上就能控制网络中链的走向。这也是所谓 51% 攻击 的由来。
参与 PoW 计算比赛的人，将付出不小的经济成本（硬件、电力、维护等）。当没有成为首个算出的“幸运儿”时，这些成本都将被沉没掉。这也保障了，如果有人恶意破坏，需要付出大量的经济成本。也有设计试图将后算出结果者的算力按照一定比例折合进下一轮比赛考虑。
有一个很直观的例子可以说明为何这种经济博弈模式会确保系统中最长链的唯一。
超市付款需要排成一队，可能有人不守规矩要插队。超市管理员会检查队伍，认为最长的一条队伍是合法的，并让不合法的分叉队伍重新排队。只要大部分人不傻，就会自觉在最长的队伍上排队。
2. PoS
权益证明，Proof of Stake，2013 年被提出，最早在 Peercoin 系统中被实现。
类似现实生活中的股东机制，拥有股份越多的人越容易获取记账权。
典型的过程是通过保证金（代币、资产、名声等具备价值属性的物品即可）来对赌一个合法的块成为新的区块，收益为抵押资本的利息和交易服务费。提供证明的保证金（例如通过转账货币记录）越多，则获得记账权的概率就越大。合法记账者可以获得收益。
PoS 是试图解决在 PoW 中大量资源被浪费的缺点。恶意参与者将存在保证金被罚没的风险，即损失经济利益。
一般的，对于 PoS 来说，需要掌握超过全网三分之一的资源，才有可能左右最终的结果。这个也很容易理解，三个人投票，前两人分别支持一方，这时候，第三方的投票将决定最终结果。
PoS 也有一些改进的算法，包括授权股权证明机制（DPOS），即股东们投票选出一个董事会，董事会中成员才有权进行代理记账。
优点: 对节点性能要求低，达成共识时间短（网络环境好的话可实现毫秒级）
缺点：没有最终一致性
3. DPOS
Delegated Proof-Of-Stake（DPOS），即股份授权股权证明。与PoS的主要区别在于节点选举若干代理人，由代理人验证和记账。其合规监管、性能、资源消耗和容错性与PoS相似。类似于董事会投票，持币者投出一定数量的节点，代理他们进行验证和记账。
工作原理：去中心化表示每个股东按其持股比例拥有影响力，51%股东投票的结果将是不可逆且有约束力的。其挑战是通过及时而高效的方法达到51%批准。为达到这个目标，每个股东可以将其投票权授予一名代表。获票数最多的前100位代表按既定时间表轮流产生区块。每名代表分配到一个时间段来生产区块。所有的代表将收到等同于一个平均水平的区块所含交易费的10%作为报酬。如果一个平均水平的区块含有100股作为交易费，一名代表将获得1股作为报酬。
优点：减少记账节点规模，属于弱中心化，效率提高。
缺点：牺牲了去中心化的概念，不适合公有链。
4. Casper（投注共识）
这是一种以太坊下一代的共识机制，属于PoS。Casper的共识是按块达成的而不是像PoS那样按链达成的。
为了防止验证人在不同的世界中提供不同的投注，还有一个简单严格的条款：如果你有两次投注序号一样，或者说你提交了一个无法让Casper合约处理的投注，你将失去所有保证金。从这一点我们可以看出，Casper与传统的PoS不同的是Casper有惩罚机制，这样非法节点通过恶意攻击网络不仅得不到交易费，而且还面临着保证金被没收的风险。
Casper协议下的验证人需要完成出块和投注两个活动。
具体参考
5. Pool验证池
基于传统的分布式一致性技术，加上数据验证机制。
优点：不需要代币也可以工作，在成熟的分布式一致性算法（Pasox、Raft）基础上，实现秒级共识验证。
缺点：去中心化程度不如bictoin；更适合多方参与的多中心商业模式。
