三. 区块链系统的核心之一-分布式共识机制
Posted
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了三. 区块链系统的核心之一-分布式共识机制相关的知识，希望对你有一定的参考价值。
参考技术A 拜占庭将军问题（Byzantine Generals Problem），是由莱斯利·兰波特在其同名论文中提出的分布式对等网络通信容错问题。在分布式计算中，不同的计算机通过通讯交换信息达成共识而按照同一套协作策略行动。但有时候，系统中的成员计算机可能出错而发送错误的信息，用于传递信息的通讯网络也可能导致信息损坏，使得网络中不同的成员关于全体协作的策略得出不同结论，从而破坏系统一致性。这个难题被称为“拜占庭容错”，或者“两军问题”。
拜占庭假设是对现实世界的模型化。拜占庭将军问题被认为是容错性问题中最难的问题类型之一。拜占庭容错协议要求能够解决由于硬件错误、网络拥塞或断开以及遭到恶意攻击，其他计算机和网络可能出现不可预料的行为而带来的各种问题。并且拜占庭容错协议还要满足所要解决的问题要求的规范。
在拜占庭时代有一个墙高壁厚的城邦——拜占庭，高墙之内存放在世人无法想象多的财富。拜占庭被其他10个城邦所环绕，这10个城邦也很富饶，但和拜占庭相比就有天壤之别了。
拜占庭的十个邻居都觊觎它的财富，并希望侵略并占领它。但是，拜占庭的防御非常强大，任何单个城邦的入侵行动都会失败，而入侵者的军队也会被歼灭，使得该城邦自身遭到其他互相觊觎对方的九个城邦的入侵和劫掠。
拜占庭的防御很强，十个城邦中要有一半以上同时进攻才能攻破它。也就是说，如果有六个或者以上的相邻城邦一起进攻，他们就会成功并获得拜占庭的财富。然而，如果其中有一个或者更多城邦背叛了其他城邦，答应一起入侵但在其他城邦进攻的时候又不干了，也就导致只有五支或者更少的城邦的军队在同时进攻，那么所有的进攻城邦的军队都会被歼灭，并随后被其他的（包括背叛他们的那（几）个）城邦所入侵和劫掠。
这是一个由许多不互相信任的城邦构成的一个网络。城邦们必须一起努力以完成共同的使命。而且，各个城邦之间通讯和协调的唯一途径是通过信使骑马在城邦之间传递信息。城邦的决策者们无法聚集在一个地方开个会（所有的城邦的决策者都不互相信任自己的安全会在自己的城堡或者军队范围之外能够得到保障）。
城邦的决策者可以在任意时间以任意频率派出任意数量的信使到任意的对方。每条信息都包含如下的内容：“我城邦将在某一天的某个时间发动进攻，你城邦愿意加入吗？”。如果收信城邦同意了，该城邦就会在原信上附上一份签名了的或盖了图章的（以就是验证了的）回应然送回发信城邦。然后，再把新合并了的信息的拷贝一一发送给其他八个城邦，要求他们也如此这样做。最后的目标是，通过在原始信息链上盖上他们所有十个城邦的决策者的图章，让他们在时间上达成共识。最后的结果是，会有一个盖有十个同意同一时间发动进攻的图章信息包，和一些被抛弃了的包含部分但不是全部图章的信息包。
在这个过程中首先出现了第一个问题，就是如果每个城邦向其他九个城邦派出一名信使，那么就是十个城邦每个派出了九名信使，也就是在任何一个时间又总计90次的传输，并且每个城市分别收到九个信息，可能每一封都写着不同的进攻时间。
在这个过程中还有第二个问题，就是部分城邦会答应超过一个的攻击时间，故意背叛进攻发起人，所以他们将重新广播超过一条（甚至许许多多条）的信息包，由此产生许多甚至无数的足以淹没一切的杂音。
有了以上两个问题，整个网络系统可能迅速变质，并演变成不可信的信息和攻击时间相互矛盾的纠结体。
拜占庭假设是对现实网络世界的一种模型化。在现实网络世界中由于硬件错误、网络拥塞或断开以及遭到恶意攻击，网络可能出现许许多多不可预料的行为。拜占庭容错协议必须处理这些失效，并且还要使这些协议满足所要解决的问题所要求的规范。
对于拜占庭将军问题中本聪的区块链给出了比较圆满的解决方案。也就是比较圆满的解决了上述的两个问题。
拜占庭将军问题的第一个问题从本质上来讲就是时间和空间的障碍导致信息的不准确和不及时。
区块链对于第一个问题的解决方案是利用分布式存储技术和比特流技术（BT技术，一种新型的点对点传输技术，具有节点同时作为客户端和服务器端和没有中心服务器等特点），将整个网络系统内的所有交易信息汇总为一个统一的，分布式存储的，近乎实时同步更新的电子总账。统一的分布式共同账本就解决了空间障碍问题；而近乎同步进行的，实时的，持续的对所有账本备份的更新、对账则解决了时间障碍问题。
这个过程较具体一点的描述大概是将区块链系统内所有的交易活动的记录数据统一于一种标准化的总帐上；区块链系统的每一个节点都会保存一份总帐的备份；所有总帐的备份都是在实时的，持续的更新、对账、以及同步着。区块链系统的每一个节点能在这本总帐里记上添加记录；每一笔新添加的记录都会实时的广播到区块链系统内；所以在每一个节点上的每一份总帐的备份都是几乎同时更新的，并且所有的总帐的备份保持着同步。
拜占庭将军问题的第二个问题从本质上来讲就是关于信息过量问题和信息干扰问题。信息过量和信息干扰问题导致决策延迟，甚至决策系统崩溃而无法决策。
区块链对于第二个问题的解决方案是区块链系统的任何一个节点在发送每一笔新添加的记录时需要附带一条额外的信息。对区块链系统的任何一个节点来说这条额外的信息的获得都是有成本的，并且只能有一个节点可以获得。这样就解决了区块链系统的任何一个节点新添加额外信息时的信息多且乱而无法达成一致的问题。在这里，区块链系统的任何一个节点获得那条附带的额外的信息的过程就是著名的工作量证明机制。
共识机制主要解决区块链系统的数据如何记录和如何保存的问题。工作量证明机制就是要求区块链系统的节点通过做一定难度的工作得出一个结果的过程。
区块链系统中某节点生成了一笔新的交易记录，并且该节点将这笔新的交易记录向全网广播。全网各个节点收到这个交易记录并与其他所有准备打包进区块的交易记录共同组成交易记录列表。在列表内先对所有交易进行两两的哈希计算；再对以获得的哈希值进行哈希计算获得Merkle树和Merkle树的根值；把Merkle树的根值及其他相关字段组装成区块头。
各个节点将区块头的80字节数据加上一个不停的变更的区块头随机数一起进行不停的哈希运算（实际上这是一个双重哈希运算）；不停的将哈希运算结果值与当前网络的目标值做对比，直到哈希运算结果值小于目标值，就获得了符合要求的哈希值，工作量证明也就完成了。
分布式的区块链系统是一个动态变化的系统（硬件的运算速度的增长，节点参与网络的程度的变化）。系统的不断变化必然带来系统的算力的不断变化。而算力的变化又会导致通过消耗算力（工作）来获得符合要求的哈希值的速度的不同。最终的结果会是区块链的增长速度会有巨大的不同。这是一个很大的问题。为了解决这个问题，区块链系统自动根据算力的变化对工作难度进行调整。也就是采用移动平均目标的方法来确定，难度控制为每小时生成区块的速度为某一个预定的平均数。
在区块链系统中一个符合要求的哈希值是由N个前导零构成，零的个数取决于网络的难度值。为了使区块的形成时间控制在大约十分钟左右，区块链系统采用了固定工作难度的难度算法。难度值每2016个区块调整一次零的个数。
新的难度值是根据前2015个区块（理论上应该是2016个区块，由于当初程序编写时的失误造成了用2015而不是2016）的出块时间来计算。
难度 = 目标值 * 前2015个区块生成所用的时间 / 1209600 （两周的秒钟数）
这样通过规定的算法，区块链系统就保证所有节点计算出的难度值都一致，区块的形成时间大约一致在十分钟左右。
（1）结果不可控制。其依赖机器进行哈希函数的运算来获得结果；计算结果是一个随机数；没有人能直接控制计算的结果。
（2）计算具有对称性。就是结果的获得和结果的验收需要的工作量是不同的。计算出结果所需要的工作量远远大于验收结果所需要的工作量。
（3）计算的难度自动控制。为了使区块的形成时间控制在大约十分钟左右，区块链系统自动控制了每一个符合要求的哈希获得为大约在十分钟左右。
第一，方法简单易行。
第二，系统达成共识容易，节点间不需要太多的信息交换。
第三，系统比较牢固可靠，任何破坏系统的企图都需要投入大到得不偿失的成本。
第一，消耗大量的算力，也就是浪费能源和其他资源。
第二，区块的确认时间比较长，并且难以缩短。
第三，新创立的区块链非常容易受到算力攻击。
第四，容易产生区块链分叉，稳定的区块链需要多个确认，并且这种状况可能不断持续下去。
第五，算力的逐渐集中导致与去中心化的系统设计基础的冲突日益明显。
权益证明机制是一种工作量证明机制的替代方法，试图解决工作量计算浪费的问题.目前其成功的应用是点点币区块链系统。
权益证明不要求区块链系统的节点完成一定数量的计算工作，而是要求区块链系统的节点对某些数量的钱展示所有权。
权益证明机制首先应用于点点币区块链系统中。
点点币区块链系统的区块生成时，节点需要构造一个“钱币权益”交易，即把自己的一些钱币和预先设定的奖励发给自己。进行哈希计算时，哈希值的计算只同交易输入、一些附加的固定数据以及当前时间（是一个表示自1970年1月1日距离当前时刻的秒数的正数）有关。然后，根据类似工作量证明的要求来检查这个哈希值是否正确。
点点币区块链系统的权益证明机制除了设定了哈希计算难度与交易输入的“币龄”成反比外，其与工作量证明机制非常类似。其中，币龄的定义为交易输入大小和它存在时间的乘积。权益证明机制中哈希值只和时间和固定的数据有关，因而没有办法通过多完成工作来快速获取它。
每个点点币区块链系统的交易的输出都有一定的几率来产生有效的正比于币龄和交易货币数量的工作。
第一，缩短了共识达成的时间。
第二，不再需要大量消耗能源。
第一，还是需要哈希计算。
第二，所有的确认都只是一个概率上的表达，而不是一个确定性的事情，有可能受到其他攻击影响。
授权股份证明机制类似于权益证明机制，是比特股BitShares采用的区块链公识算法。授权股份证明机制是民主选举和轮流执政相结合方式来确定区块的产生。
授权股份证明机制是先由节点选举若干代理人，由代理人验证和记账。其他方面和权益证明机制相似。
每个节点按其持股比例拥有相应的影响力，51%节点投票的结果将是不可逆且有约束力的。为达到及时而高效的方法达到51%批准的目标。每个节点可以将其投票权授予一名节点。获票数最多的前100位节点按既定时间表轮流产生区块。每名节点分配到一个时间段来生产区块。
所有的节点将收到等同于一个平均水平的区块所含交易费的10%作为报酬。
第一，大幅缩小参与验证和记账节点的数量，
第二，可以快速实现共识验证。
主要缺点就是仍然无法摆脱对代币的依赖。
在分布式计算上，不同的计算机透过讯息交换，尝试达成共识；但有时候，系统上协调计算或成员计算机可能因系统错误并交换错的讯息，导致影响最终的系统一致性。
拜占庭将军问题就根据错误计算机的数量，寻找可能的解决办法，这无法找到一个绝对的答案，但只可以用来验证一个机制的有效程度。
而拜占庭问题的可能解决方法为：
在 N ≥ 3F + 1 的情况下一致性是可能解决。其中，N为计算机总数，F为有问题计算机总数。信息在计算机间互相交换后，各计算机列出所有得到的信息，以大多数的结果作为解决办法。
第一，系统运转可以摆脱对代币的依赖，共识各节点由业务的参与方或者监管方组成，安全性与稳定性由业务相关方保证。
第二，共识的时延大约在2到5秒钟。
第三，共识效率高，可满足高频交易量的需求。
第一，当有1/3或以上记账人停止工作后，系统将无法提供服务；
第二，当有1/3或以上记账人联合作恶，可能系统会出现会留下密码学证据的分叉。
小蚁改良了实用拜占庭容错机制。该机制是由权益来选出记账人，然后记账人之间通过拜占庭容错算法来达成共识。
此算法在PBFT基础上进行了以下改进：
第一，将C/S架构的请求响应模式，改进为适合P2P网络的对等节点模式；
第二，将静态的共识参与节点改进为可动态进入、退出的动态共识参与节点；
第三，为共识参与节点的产生设计了一套基于持有权益比例的投票机制，通过投票决定共识参与节点（记账节点）；
第四，在区块链中引入数字证书，解决了投票中对记账节点真实身份的认证问题。
第一，专业化的记账人；
第二，可以容忍任何类型的错误；
第三，记账由多人协同完成，每一个区块都有最终性，不会分产生区块链分叉；
第四，算法的可靠性有严格的数学证明来保证；
第一，当有1/3或以上记账人停止工作后，区块链系统将无法提供服务；
第二，当有1/3或以上记账人联合作恶，且其它所有的记账人被恰好分割为两个网络孤岛时，恶意记账人可以使区块链系统出现分叉，但是会留下密码学证据；
瑞波共识机制是全体节点选取出特殊节点组成特殊节点列表，由特殊节点列表内的节点达成共识。
初始特殊节点列表就像一个俱乐部，要接纳一个新成员，必须由51%的该俱乐部会员投票通过。共识遵循这核心成员的51%权力，外部人员则没有影响力。波共识机制将股东们与其投票权隔开，并因此比其他系统更中心化。
瑞波共识机制参与共识形成的只有特殊节点，大大的减少了共识形成的时间。在实践中，瑞波区块链系统达成共识需要3-6秒钟，远远快于比特币区块链系统的10分钟。同时瑞波区块链系统对并发交易的处理达到每秒数万笔，而比特币区块链系统只有每秒7笔。
瑞波共识机制处理节点意见分歧的方式也是不同的。瑞波的信任节点对于新区块的创造进行协商的时间是区块链更新前。先协商，达成共识后再对区块链进行更新。
由于瑞波共识机制的共识是由特殊节点达成的，普通节点并不需要维护一个完整的历史账本。各个节点可以根据自己的业务需要选择同步同步完整的历史账本或者任意最近几步的账本。这也意味着对存储空间和网络流量需求的减少。
瑞波共识机制取消了挖坑的发行货币机制，采用了原生货币（1000亿枚）的方式发币，从而大量的避免了挖矿的天量能耗。
分布式系统共识机制：一致性算法设计思想
分布式系统共识机制：一致性算法设计思想
这次以一个宏观的角度去总结 自己学习过的一致性算法。一致性算法的目标就是让分布式系统里的大部分节点 保持数据一致。
区块链中的共识算法，pow、pos这类就属于这个范围，但他们仅仅是在区块链领域内应用的，下面介绍一致性算法是在分布式系统中 应用广泛的，当然也肯定适用于区块链，并且最后我总结了他们的设计思想，其实是有一定套路的。
Paxos 算法
首先是paxos算法，他是在大量工程实践中得到检验的，google很多项目和大数据组件zookeeper中都用它。他是实现是很复杂的，但是基本思想不难理解。
节点角色
paxos的节点有三种角色，分别是：
第一类是提案者，负责提出议案，也就是要同步的数据。
第二类 批准者，提案者提出的提案 必须获得超过半数的 批准者的投票后才能通过。
第三类 学习者。不参与提案，只负责接收已确定的提案，一般用于提高集群对外提供 读 服务的能力。
算法流程
算法具体流程主要有三个阶段：
首先是 Prepare阶段，提案者选择一个提案编号N，向批准者们发送 这个编号的Prepare请求。批准者收到请求后，判断N是不是大于 本地已经响应的Prepare请求的编号，是的话就将这个编号反馈给提案者，同时不会再批准 编号小于N的提案。
然后是 Accept阶段，如果提案者收到 超过半数批准者的响应，就发送一个针对[N,val]提案的Accept请求 给批准者，val是提案值。然后批准者接受对应值并返回给提案者一个响应。
到这时候，批准者和提案者都达成了共识。
最后就进入Learn阶段，这个阶段不属于选定提案的过程，提案者将通过的提案 同步到所有的学习者。
最终大部分节点就会达成共识。
很明显，这个算法不适用于存在拜占庭节点的分布式系统，只能适用于普通的分布式系统。
Raft 算法
虽然Paxos的原理比较容易理解，但是它在工程上的实现是非常复杂的，所以出现了Raft算法，是Paxos算法的一种简化实现。基本思路也差不多。
节点角色
同样的，节点有三种角色：
首先是 follower追随者，是集群的初始状态，节点在加入时默认是追随者，也就是从节点。
然后是 candidate候选人，是在选举的时候，被投票者的称谓。这是一个中间角色，比如followerA投票给followerB，那followerB的角色就是candidate。
最后是 leader主节点，用来接收用户请求，进行数据同步。
核心机制
RAFT算法分为两个阶段：Leader选举和日志复制。
首先看leader是如何选出来的。
leader选举
算法刚开始时，所有结点都是Follower，每个结点都会有一个定时器，在收到Leader 的消息时就会重置定时器。如果定时器超时，说明一段时间内没有收到 Leader 的消息，那么就认为 Leader不存在了，那么该结点就会转变成 Candidate，准备竞争Leader。
成为 Candidate 后，节点会向其他结点发送 请求投票的请求，其他结点在收到请求后 会判断是否投给他并返回结果。Candidate如果收到了半数以上的投票 就可以成为Leader，成为之后会在任期内 定期发送心跳消息 通知其他结点 新的 Leader 信息，用来重置其他节点的定时器，避免其他结点成为 Candidate。
日志复制
leader选举出来后，就要开始同步数据。
由leader收到客户端的请求，会将请求包装成日志包的形式发到其它节点，这个过程叫做日志复制。其它节点接收到数据后向主节点响应ACK。
leader等待集群中超过一半的节点响应后， 再向客户端回复数据已接收。此时进入 数据已提交的状态。
最后 Leader 节点再向其它节点 告知数据状态已提交，其它节点开始commit自己的数据，此时集群达到主节点和从节点的一致。
raft算法和刚才介绍的paxos算法，都假设不存在拜占庭将军问题，只考虑节点宕机、网络分区、消息不可靠等问题。下面这类算法就考虑到节点作恶的情况。最经典实用的是pbft，之前也多次介绍过这个算法的实现细节，但这次以另一种的角度去解读
PBFT
首先，也是分为不同店节点角色，分别是：
主节点，负责将交易打包成区块，每轮共识过程只能有一个主节点。
副本节点，负责共识投票，每轮共识过程中有多个副本节点。
流程：
客户端发送请求给主节点
主节点广播请求给其它节点，节点执行PBFT算法的三阶段共识流程。
三阶段流程后，返回消息给客户端。
客户端收到来自 f+1 个节点的相同消息后，代表共识已经正确完成。
基于投票的共识算法 其实基本就是一个套路：确定一个leader提出提案，其他节点负责投票。根据投票结果来确定提案是否通过。当主节点提出提案后，其他节点的 投票和收集投票 都由各个节点单独完成的，这是因为有拜占庭节点的存在，节点只相信自己获取到的投票信息，每一个节点 基于自己收集的消息来确定 该提案是否形成了共识。
所以就设计了四个阶段：
首先pre-prepare阶段 就是主节点向副本节点发送提案，副本节点接收提案并进行验证，但并不知道其它节点的状态。
在prepare阶段，每个合法的节点都接收到至少2/3的投票数，我们将一个节点接收到至少2/3的投票数 称为事件A，显然至少2/3节点都发生了事件A，但是节点之间 不知道彼此是否发生了事件A；
所以就有commit阶段，每个节点都将 自己发生了事件A的消息 广播给其他节点，同时也收集其他节点 关于事件A的广播，我们把收集到至少2/3个节点的事件A 称作事件B。此时，每个节点都知道 至少有2/3节点都发生了事件A，那么大部分节点达成了共识。但是，客户端还不知道结果呢。
最后，在reply阶段中，每个节点都将事件B返回给客户端，此时客户端只要收集到至少f+1个节点的 事件B的广播，就可以判断系统已经形成共识。我们将收集到至少f+1个节点的事件B的广播 称作事件C。
所以，pbft设置了四个阶段就是为了保证这三个事件的发生。
Hotstuff
根据刚才的介绍，PBFT中的关键点在于 每个节点都独立做 收集投票的工作，这就导致了整个算法中 节点的工作量是重复的。而PBFT之所以这么做的原因是 节点只相信自己获取到的投票信息，如果能解决这个信任问题，那么就省去这些重复工作。HotStuff所进行的优化也就是基于此，通过使用门限签名，确保投票结果不能被伪造。
门限签名
节点角色和PBFT的角色一样，分为主节点和副本节点。
门限签名 简单介绍下：一个（k，n）门限签名方案指 由n个成员组成的签名群体，所有成员共同拥有一个公共密钥，每个成员拥有各自的私钥。只要收集到k个成员的签名，且生成一个完整的签名，这个签名可以通过公钥进行验证。
这里不去详细探讨门限签名的技术细节，主要聚焦在算法是怎样应用的。在HotStuff中，leader除了提出提案以外，还需要收集其他节点的投票，并将投票结果整合成一个 容易检查合法性但又无法伪造的证据。门限签名的特点就是，当且仅当 对同一个数据具备了足够多的子签名，才能合成一个签名，而其他人只需要验证最终的签名 就能确保整个签名构建过程是合法的。门限签名的使用，使得所有节点都可以将 收集投票信息的工作委派给leader，并可以确保leader无法作假。因此，HotStuff最终的算法复杂度是直接降低了一个量级。
核心机制
HotStuff主要是将**“leader负责收集每一轮的投票信息”**思想融合到pbft中。pbft中出现了2轮所有节点广播以及收集投票+1轮客户端收集投票。如果换成leader收集投票，需要3轮来保证这三个事件的发生。
第一阶段，收集至少2/3节点的投票，即leader节点发生了事件A，此时leader节点把这个时间点的证据保留下来，广播给其他节点。其他节点也就相当于发生了事件A；但是不知道 其他节点是否接收到leader广播的事件A；
第二阶段，所以收到事件A的节点 会发送消息给leader；leader会收集这些投票，即leader发生了事件B，同理，将这个事件B广播给其他节点，其他的节点在收到 时也相当于发生了事件B，但是还是不知道 其他节点是否有收到事件B；
第三阶段，跟第2步一样，收到事件B的节点也会发送投票给leader，leader收集，此时leader发生了事件C，同理，将这个事件广播给其他节点，其他节点收到后，就确认了共识已经达成。
总结以上几种一致性算法的设计思想，可以分成二阶段提交协议和三阶段提交协议。
二阶段提交协议
二阶段主要采取：先尝试，后提交。
可以分成两个角色：协调者和参与者。
第一阶段是提交事务请求。
协调者向参与者发送事务内容，询问是否可以执行事务提交操作，等待响应；
参与者执行事务操作，并回复协调者，执行成功则回Yes否则No。
第二阶段是执行事务提交。
如果参与者都回复Yes，那么协调者向参与者发送 提交请求，否则发送回滚请求。
参与者根据协调者的请求 执行事务提交或回滚，并向协调者发送Ack消息。
协调者收到所有的Ack消息后，判断分布式系统事务的结果是完成还是失败。
刚才介绍的paxos和raft都是基于二阶段提交的思想实现的。
二阶段优点：
- 原理简单；
- 保证了分布式事务的原子性，要么全部执行成功，要么全部执行失败。
二阶段缺点：
- 同步阻塞：在提交执行过程中，各个参与者都在等待 其他参与者响应的过程，无法执行其他操作。
- 单点问题：只有一个协调者，协调者挂掉，整个二阶段提交流程无法执行；更严重的是，在阶段二时，协调者出现问题，那参与者会一直处于锁定事务状态中，无法继续完成事务操作。
- 数据不一致：在阶段二，协调者发送了Commit请求后，如果发生了网络故障，导致只有部分参与者收到commit请求，并执行提交操作，就导致数据不一致问题。
三阶段提交协议
因为二阶段提交有很多问题，所以出现了三阶段提交
主要的改进点是 将第一阶段分为两个阶段，先发起事务询问，再执行事务。
同时在协调者和参与者中引入超时机制。
第一阶段 事务询问
协调者向参与者发送 包含事务内容的询问请求，询问是否可以执行事务；
参与者根据自己状态判断并回复yes或no；
第二阶段 执行事务预提交
如果协调者收到大部分节点的yes，就发送preCommit请求，否则发布abort请求；
参与者如果收到preCommit，就执行事务然后返回Ack。如果收到abort或者超时，就中断事务；
第三阶段是 执行事务提交
如果协调者收到大部分节点是Ack，就发送doCommit请求；
参与者收到doCommit就提交事务并返回响应；
协调者收到响应后，判断是完成事务还是中断事务；
pbft和hotstuf这类算法的基本思想就是三阶段提交协议。
三阶段的优点：
- 降低了二阶段的同步阻塞范围，在第二阶段，只要参与者收到preCommit请求，就会执行事务，不会一直阻塞。
- 解决单点问题：进入阶段三会出现两种情况： 1：协调者出现问题； 2：协调者与参与者之间出现网络故障； 都会导致参与者无法收到doCommit请求，但参与者在超时之后都会提交事务。
三阶段的缺点
- 还是会存在数据分区问题：参与者收到preCommit请求，此时如果出现网络分区，协调者与参与者之间无法进行正常网络通信，参与者在超时之后还是会进行事务提交，就会出现数据不一致。当然，这是分布式系统的通病，要保持一致性和可用性，就必然要牺牲分区容错性，这是分布式系统的不可能三角，也就是cap理论。所以不管是二阶段提交还是三阶段提交，数据分区是不可避免的。
以上是关于三. 区块链系统的核心之一-分布式共识机制的主要内容，如果未能解决你的问题，请参考以下文章