在
区块链系统中，共识算法作为保证分布式节点间数据一致性的算法，可以被分为两大类，即概率一致性算法和绝对一致性算法。
概率一致性算法指在不同分布式节点之间，有较大概率保证节点间数据达到一致，但仍存在一定概率使得某些节点间数据不一致。
对于某一个数据点而言，数据在节点间不一致的概率会随时间的推移逐渐降低至趋近于零，从而最终达到一致性。
例如工作量证明算法（Proof of Work, PoW）、股份证明算法（Proof of Stake, PoS）和委托股权证明算法（Delegated Proof of Stake, DPoS）都属于概率一致性算法。
而绝对一致性算法则指在任意时间点，不同分布式节点之间的数据都会保持绝对一致，不存在不同节点间数据不一致的情况。
例如分布式系统中常用的 PAXOS 算法及其衍生出的 RAFT 算法等，以及拜占庭容错类算法（类 BFT 算法）。
一般而言，回顾上面所述 CAP 原理，概率一致性算法保证了系统的可用性而牺牲了系统的一致性，绝对一致性算法则与之相反，保证了系统的一致性而牺牲了系统的可用性。
各算法之间对比如下表，★ 数量越多，代表相应对比项表现越好。
迅雷链的业务需求保证分布式系统中的强一致性，并具备一定的容错和防拜占庭节点作恶的能力，因此选择类 BFT 算法作为共识算法。
我们在实用拜占庭容错（PBFT）算法的基础上，为了解决算法网络消耗高的问题，作出了一些优化，提高了算法的可用性。
下面首先介绍区块链中最常用的强一致性算法——实用拜占庭容错（PBFT）算法。
假设系统中节点数量为 R=3f+1，其中f为系统中拜占庭节点的数量。
在发送消息的时候通过环境状态、时间戳、请求、回复信息，客户端同样等待 2f+1 个回复，同时保证签名、时间戳、回复信息来保证一致。
这里存在两种情况，一种是客户端请求超时，那就再发送一次，如果是主节点P出故障，那就改变环境状态，新选一个 P 节点。保证第二次的执行过程。
在实际的算法流程中，PBFT 算法定义三个任务阶段：预准备（pre-prepare）、准备(prepare)、确认(commit)。
预准备：P 分配一个系统序列号 ID，发送给所有 B 节点。
发送格式（环境状态、ID、信息摘要、客户端请求）。B 节点验证信息摘要和客户端请求一致，验证当前环境状态编号。
准备：B 节点在接收信息后加上自己的消息日志，发送至其余节点。P 和 B 节点同时验证消息签名，如果一致，那么就把验证通过写入消息日志。每个节点在准备阶段对每个副本节点验证预准备的消息和准备消息一致性检查完毕。
确认：在前面两个极端一切正常的话，在同一系统环境中，所有请求序号一致，验证消息一致，简单理解就是确认 2f+1 个节点发送了之前发送的序号和消息。
每个节点接受确认消息，签名正确；消息的系统环境编号V与节点的环境编号 V 一致；消息的序号 ID 满足序列要求。节点通过确认至少 2f+1 个副本信息，保证整个系统中算法的正确性。
图中，C 我们认为是客户端，0、1、2、3 是分布式系统中的节点成员，其中由 0 节点提议区块，1、2、3 节点对提议出来的区块进行投票，其中 3 节点已发生故障。我们默认 3 发送信息为无效。那么 PBFT 算法执行的流程如下：
1. C 发起一笔请求到 0 号节点。
2. 节点 0 开始对请求排序编号，并把请求序号发送到 1、2、3 节点。
3. 1、2 节点互相之间和 0 节点之间发送消息。
4. 0、1、2 之间确认 0 节点的分配序号，互相确认。
5. 0、1、2 确认信息回复 C。
6. 客户端 C 判断收到确认是否在 2f+1 内，确认结果。
在每一轮共识分三个阶段达成共识：Pre-Prepare、Prepare 和 Commit，整个流程如下：
1. 从全网节点选举出一个提议节点（Proposer），新区块由提议节点负责生成。
2. 每个节点把客户端发来的交易向全网广播，提议节点将从网络收集到需放在新区块内的多个交易排序后存入列表，并将该列表向全网广播。
3. 每个节点接收到交易列表后，根据排序模拟执行这些交易。所有交易执行完后，基于交易结果计算新区块的哈希摘要，并向全网广播。
4. 如果一个节点收到的 2f 条来自其它节点发来的摘要都和自己的相同，就向全网广播一条 commit 消息。
5. 如果一个节点收到 2f+1 条 commit 消息，即可提交新区块及其交易到本地的区块链和状态数据库。
版权申明：本内容来自于互联网，属第三方汇集推荐平台。本文的版权归原作者所有，文章言论不代表链门户的观点，链门户不承担任何法律责任。如有侵权请联系QQ：3341927519进行反馈。
